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

Paul Eggert eggert at cs.ucla.edu
Fri Jan 26 01:05:17 UTC 2018


On 01/25/2018 04:52 PM, Guy Harris wrote:
> 1) applications should not require a knowledge of "the" offset from UTC (given that there may not be any such thing as "the" offset from UTC), e.g. don't use timezone;

Yes.

> 2) applications that need to know offset from UTC at any given instance should do so by doing strftime(buf, bufsize, "%z", tm) and parsing the result;

Sort of. That method works only if the UTC offset is a multiple of 1 
minute. This is a safe assumption for modern civil timestamps, but if 
you want to go back before 1972 in tzdb, or if you want to support 
odd-but-valid POSIX TZ strings, a more-reliable approach is to call 
localtime and gmtime on the same timestamp, and subtract the results by 
hand with the usual Gregorian rules. (And yes, that's what some 
applications do - of course it's much easier and faster to use tm_gmtoff 
when available.)

> 3) applications that need to know the the time zone abbreviation at any given instance should do so by doing strftime(buf, bufsize, "%Z", tm);

Yes.

> 4) applications should not require a knowledge whether daylight savings time (or whatever it's called) has ever been, or will ever be, in effect in the current locale/tzdb region.

Yes.

> What, in real-world terms, can they assume about tm_isdst?  That it indicates some either implementation-specified or unspecified notion of "Daylight Saving{s} Time", which might or might not be set e.g. during a Ramadan time shift?  Or that it's true iff the time is shifted from some implementation-specified or unspecified notion of "standard time" (which might not, in the Republic of Ireland, correspond to Irish Standard Time)?

Portable code shouldn't use tm_isdst; it's a vestigial interface. Alas, 
too many programs do use it, I think mostly because programmers 
not-unnaturally think it must exist for a reason.



More information about the tz mailing list