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