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

[Guy Harris]

On Jan 25, 2018, at 4:03 PM, Paul Eggert <eggert at cs.ucla.edu> wrote:

> On 01/25/2018 01:34 PM, Guy Harris wrote:
>> if we have three flavors of time per year, with different names/abbreviations/offsets, that would require a POSIX API change
> 
> It doesn't require an API change, as the GNU C library, FreeBSD, and other libraries conform to POSIX in this area while still supporting applications that successfully use and deal with three or more flavors of time per year.
> 
> This works because the parts of the POSIX API that you're referring to are vestigial: although they suffice for many usages, they're inadequate for older timestamps and in some cases they're even inadequate for this years' planned timestamps. General-purpose POSIX applications cannot rely on the vestigial parts of the POSIX API: instead, when querying TZ settings they must stick to a subset of the POSIX API (the "non-vestigial" part) that works even when the implementation is configured to use Morocco time, or Los Angeles time including the 2007 DST rule changes, or whatever. This non-vestigial API subset includes calls to the localtime and strftime functions and invocations of the 'date' command; it excludes vestigial interfaces such as the 'timezone', 'daylight', and 'tzname' variables, all of which are supported by glibc etc. as per POSIX and all of which a general-purpose application should not use.

So presumably this means that:

	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;

	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;

	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);

	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.

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)?