[tz] Austin Group POSIX TZ changes and Time Zone Taxonomy

[Brian Inglis]

On 2023-02-22 15:48, Paul Eggert wrote:
> On 2/22/23 11:19, Brian Inglis via tz wrote:
> 
>>      https://www.austingroupbugs.net/view.php?id=1619    TZ=Area/Location
>>
>> Some of the zones could be categorized as they have proposed, but that uses 
>> terminology that I don't think we would approve of, leaves a lot of zones in 
>> the tzdb unsupported and unaddressed, and omits a whole reality which I have 
>> attempted to categorize in the attached.
> 
> Not sure what wording improvements you have in mind. Of the timezones you 
> mentioned, the only thing the Austin Group proposal would seem to rule out is 
> the rarely used TZDB option of installing leap seconds as standard so that 
> TZ="Etc/UTC", TZ="GMT0", etc. have leap seconds. Current POSIX already prohibits 
> leap seconds for TZ="GMT0", TZ="GMT-0" and TZ="GMT+0"; if POSIX adds a similar 
> prohibition against leap seconds in TZ="Etc/UTC" that isn't much of a stretch.

I see problems with their terminology, why I am suggesting a taxonomy for time 
zone categories that we could develop, for them to use to communicate in terms 
common to us both.

> Nothing in the proposed wording would prohibit other legacy names like TZ="CET" 
> or TZ="Japan" as extensions, any more than the current POSIX wording does.

They only allow Area/Location, and I have issues with that wording, and not 
Japan, Etc/GMT..., or posix/America/.../... from what I can see of their edits, 
except under the headings of special and/or implementation defined: they should 
be aware that those are mostly *standard* time zone, not timezone, identifiers.

They do not take account of the fact that a system may not use UTC, and POSIX 
apps which do, may have to accomodate that, and that the zone identifier may 
have three levels below that.

> The biggest glitch I can see with the wording as applied is that it says that 
> TZ="America/New_York" will set "The timezone names for standard time (std) and, 
> if observed, for DST (dst) to be used by tzset()." This suggests that there are 
> at most two abbreviations (one for standard time and maybe another for DST). 
> This is not how it works - for example, TZ="America/Los_Angeles" supports five 
> abbreviations (LMT, PDT, PPT, PST, PWT) to cover past historical practice.

That wording is also questionable - if they mean time zone identifiers or 
abbreviations they should say so, not talk about geography which may be unrelated.
They also need to know that their model is inadequate and four transitions a 
year between two offsets are now common in many zones, plus any political 
changes to be made need to be allowed for.
So all tzset can do is set the current offset and support a number of subsequent 
transitions.
Their wording should reflect that the offset changes are not necessarily binary 
or really anything to do with DST, but alternate or alternative offsets from 
standard for political or religious reasons.

> Presumably this glitch is related to POSIX also considering adding support for 
> tm_gmtoff and tm_zone - do you know what's going on there?

Added in	https://www.austingroupbugs.net/view.php?id=1533

See also	https://www.austingroupbugs.net/view.php?id=1613

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry