[tz] Austin Group POSIX TZ changes and Time Zone Taxonomy
Brian Inglis
Brian.Inglis at Shaw.ca
Thu Feb 23 15:12:57 UTC 2023
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
More information about the tz
mailing list