[tz] OpenJDK/CLDR/ICU/Joda issues with Ireland change

Guy Harris guy at alum.mit.edu
Thu Jan 25 03:56:54 UTC 2018

On Jan 24, 2018, at 5:28 PM, Yoshito Umaoka <yoshito_umaoka at us.ibm.com> wrote:

> Guy Harris <guy at alum.mit.edu> wrote on 01/24/2018 05:17:24 PM:
> > From: Guy Harris <guy at alum.mit.edu> 
> > To: Yoshito Umaoka <yoshito_umaoka at us.ibm.com> 
> > Cc: Stephen Colebourne <scolebourne at joda.org>, Time Zone Mailing 
> > List <tz at iana.org>, tz <tz-bounces at iana.org> 
> > Date: 01/24/2018 05:17 PM 
> > Subject: Re: [tz] OpenJDK/CLDR/ICU/Joda issues with Ireland change 
> > 
> > On Jan 24, 2018, at 1:17 PM, Yoshito Umaoka <yoshito_umaoka at us.ibm.com> wrote:
> > 
> > > CLDR XML (or JSON) data is consumed by other projects such as ICU 
> > and Java, and these external projects know those offsets.
> > > CLDR only specifies daylight saving time name used for Europe/
> > Dublin is "Irish Standard Time".
> > > ICU/Java imports zoneinfo from tz database, and obtain offset at a
> > given time, then decide whether it's in standard time or daylight time.
> > 
> > The tz binary database has, for all transition times, an indication 
> > of whether, after the transition, you are in "DST".  If the tz 
> > binary database is what Java time zone code imports, it doesn't need
> > to look at offsets to determine whether the times are standard or 
> > "DST", it can just use those values.  (I say "DST" because that's 
> > used to set tm_isdst.)
> > 
> I cannot speak for Java. 
> ICU does not use the tz binaries - ICU generates own binary resources 
> for tzdata source files. The information equivalent to tm_isdst is stored 
> in the ICU binary format.

So ICU then presumably has no need to check the raw and actual offsets to determine whether "DST" is in effect; it could just use the "is this DST?" information - and, if it could, it *should*.

If that information is available to the Java code in question, it should do so as well.  If not, it should be *made* available to the Java code.

> In addition to this, ICU also store raw-offset 
> and DST saving amount, that is not available in the tz binaries. ICU preserve 
> the information for supporting some legacy APIs - getRawOffset, etc.. 

So by "legacy" I assume those APIs are deprecated.

Note that class TimeZone:



has, in both C++ and Java, a getRawOffset() member that returns "the TimeZone's raw GMT offset (i.e., the number of milliseconds to add to GMT to get local time, before taking daylight savings time into account)".  [sic - it really says "GMT"]

If a member of class OlsonTimeZone, which is a subclass of TimeZone, corresponds to a tzdb region as specified by a tzid such as "Europe/Berlin", how does it handle the tzdb region with the tzid "America/North_Dakota/New_Salem", given that, to quote the northamerica file:

	# Morton County, ND, switched from mountain to central time on
	# 2003-10-26, except for the area around Mandan which was already central time.
	# See <http://dmses.dot.gov/docimages/p63/135818.pdf>.
	# Officially this switch also included part of Sioux County, and
	# Jones, Mellette, and Todd Counties in South Dakota;
	# but in practice these other counties were already observing central time.
	# See <http://www.epa.gov/fedrgstr/EPA-IMPACT/2003/October/Day-28/i27056.htm>.
	Zone	America/North_Dakota/New_Salem	-6:45:39	-	LMT	1883 Nov 18 12:14:21
						-7:00		US	M%sT	2003 Oct 26  2:00
						-6:00		US	C%sT

and therefore its "raw GMT offset" was -7 hours prior to 02:00 local time, 2003-10-26, and -6 hours after that point, and given that getRawOffset() does *not* take a time as an argument.

I.e., if a member of class OlsonTimeZone, which is a subclass of TimeZone, corresponds to a tzdb region, and if getRawOffset() is supposed to return "the" raw offset from UTC, deprecating getRawOffset is a Very Good Idea, as there are tzdb regions that simply *do not have a raw offset from UTC independent of time*.

Is getDisplayName() also deprecated, for the same reason?  For example, in the OlsonTimeZone for "America/North_Dakota/New_Salem", the values it returns would be based on Mountain Time prior to 2003-10-26 02:00 local time and Central Time after that.

In ICU4C, useDaylightTime() "works" because it returns an "observes DST" indication for "the current (Gregorian) calendar year", although that won't work if a region chooses to start or stop observing DST at some time other than midnight, as, in the year when they switch, it "observes DST" for part of the year and doesn't "observe DST" for the rest of the year.

In ICU4J, useDaylightTime() doesn't work in the general case, but observesDaylightTime() presumably works, as it checks whether "this time zone is in daylight saving time or will observe daylight saving time at any future time" - if "is in daylight savings time" means "is in daylight savings time at this instant in time" (the "any future time" part handles the time-of-check/time-of-use issue), then in a year where a switch is done, observesDaylightTime() would return true.  (is that what the ICU4C useDaylightTime() does, too?)

> Our biggest issue with the change in 2018a/b was not actually negative 
> DST offset. The bigger issue is swapping standard/daylight saving names.

The issue that started this whole thing off is:


"The time for general purposes in the State (to be known as standard time) shall be one hour in advance of Greenwich mean time throughout the year, and any reference in any enactment or any legal document (whether passed or made before or after the passing of this Act) to a specified point of time shall be construed accordingly unless it is otherwise expressly provided."

Then there's


"Notwithstanding section 1 (1) of the Standard Time Act, 1968, the time for general purposes in the State shall during a period of winter time be Greenwich mean time, and during such a period any reference in any enactment or any legal document (whether passed or made before or after the passing of this Act) to a specified point of time shall be construed accordingly unless it is otherwise expressly provided."

which I read as saying "during Winter, we're one hour *behind* standard time".

So "standard time" in Ireland doesn't mean the same thing it means in most other countries, and, presumably, a properly internationali{s,z}ed program would, in the middle of summer, report that Ireland is on Irish Standard Time or something such as that.

Is that what currently happens, if the current locale is an Irish locale and the current tzdb region is the "Europe/Dublin" region, with code using the ICU and the CLDR?

And a question for somebody familiar with Irish conventions - what do they call the time that's in effect during non-summer-time - "Greenwich Mean Time"?

More information about the tz mailing list