On Jan 25, 2018, at 4:03 PM, Paul Eggert <eggert@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)?