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.