[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