Austin Group POSIX TZ changes and Time Zone Taxonomy
Hi folks, Saw that the Austin Group is proposing to support *some* time zones in POSIX issue 8; see: 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. Perhaps some here would like to come up with better facts, names, terminology, and wording, and propose an update to the Austin Group, that better reflects what exists, and what they are meant to be standardizing? If they are going to standardize this, they should either do it properly, or drop it entirely, maintaining the status quo, as they are not going to be helping with their inaccurate terminology, and limited support! -- 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
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. 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. 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. 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?
Date: Wed, 22 Feb 2023 14:48:17 -0800 From: Paul Eggert via tz <tz@iana.org> Message-ID: <c806cfc3-ba88-4533-be84-abb97b8d3330@cs.ucla.edu> | Not sure what wording improvements you have in mind. Nor am I. POSIX bug 1619 is one of mine, which has/had nothing to do with the TZ definition, that change just got bolted on as an freebie... | 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()." Yes, there is unfortunately a very limited understanding of how local time sometimes works in that group. | 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? That happened. If you want I will dig out the bug number. When the next draft appears I will be checking all of the time related structs & funcs again. kre
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
Time zone mailing list wrote in <07fb0dba-622e-4d46-7f0f-7618a014621e@Shaw.ca>: |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 ... |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. I think you are over-nitpicky here. |> 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, \ The text reads If TZ is of the third format (that is, if the first character is not a <colon> and the value does not match the syntax for the second format), the value indicates either a geographical timezone or a special timezone from an implementation-defined timezone database. Typically these take the form Area/Location as in the IANA timezone database as well as Implementations are encouraged to incorporate the IANA timezone database into the timezone database used for TZ values specifying geographical and special timezones, and to provide a method to allow it to be updated in accordance with RFC 6557. Given other standards, i feel this is very forgiving. Note the word "typically". ... |They do not take account of the fact that a system may not use UTC, \ The UNIX epoch based on UTC is basically all it knows. Even furthermore, with the last issue parts were changed like so The DESCRIPTION is updated to refer to "seconds since the Epoch" rather than "seconds since 00:00:00 UTC (Coordinated Universal Time), January 1 1970" for consistency with other time functions. I would rather have liked to see a future where TAI is distributed in conjunction with a current leap second offset. (And i mean, you know, have another 8-bit for a 127 hours counter and a positive / negative indicator bit should be doable, if you want good time keeping.) Instead some empowered ones have voted to change civil time keeping aka UTC a decade into the future, and most likely after a negative leap is applied, causing havoc (here and there), for nothing but the purpose of software which does not deal with leap seconds (in the timespace outside of 1970 to ~2035, where leap seconds of course exist), loosing the only remaining affiliation that the western white man has to nature, the relation to the sun. Maybe i am also exaggerating (as the relation to the sun basically always ever meant you can piss without shadow in Greenwhich, at noon, maybe). In short -- i feel the complain on UTC is a bit excessive. |and POSIX |apps which do, may have to accomodate that, and that the zone identifier \ |may |have three levels below that. ... |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 follow due established identifiers as used by Olson then IANA, to which they explicitly refer, no? If i would feel the spur in my side then all the many threads about identifiers that were battered on this list could be quoted. My personal opinion leads towards UN/LOCODE, because trade and business is anyway all you are interested in, and they are well received and widely known under normal citizens like myself. And under 42000 options almost everybody will find one to accept in peace. |They also need to know that their model is inadequate and four transitions \ And also, all the western timekeeping will fail if states like China would really use their very own native sun-directed time, instead of some friendly western-fitted one. And IETF to cement internet times like zone = ("+" / "-") 4DIGIT ; Signed four-digit value of hhmm representing ; hours and minutes east of Greenwich (that is, ; the amount that the given time differs from ; Universal Time). Subtracting the timezone ; from the given time will give the UT form. ; The Universal Time zone is "+0000". And on IETF an old hand said we need more [named] zones [thus]. But that is surely off-topic for POSIX. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Date: Thu, 23 Feb 2023 08:12:57 -0700 From: Brian Inglis via tz <tz@iana.org> Message-ID: <07fb0dba-622e-4d46-7f0f-7618a014621e@Shaw.ca> | I see problems with their terminology, I don't see a lot of point arguing about terminology, if we can get them to handle the concepts properly, that's enough. | They only allow Area/Location, No, that is not what the text says. It does say "Typically these take the form Area/Location as in the IANA timezone database." but that is not "only allow". The original proposal assumed that was all that was needed, but not the text that was eventually adopted. | They do not take account of the fact that a system may not use UTC, If it is a POSIX system, modified (as in no leap seconds) UTC is what it uses. If it isn't a POSIX system, then what the POSIX standard says is irrelevant. | may have to accomodate that, and that the zone identifier may | have three levels below that. The number of levels is immaterial. The spec allows anything which is does not start with a ':' (which remains implementation defined) and which is not in the form of an old style POSIX TZ string to be a TZ identifier. Anything. | They also need to know that their model is inadequate and four | transitions a year between two offsets are now common in many zones, That's (partly) why the old style TZ string was (finally) accepted as inadequate. There are no limitations on the number of transitions in the new form. There still are issues with the definition (and setting, and use) of tm_isdst - but those are largely inherited from C, and really need to be fixed there (first). | Their wording should reflect that the offset changes are not necessarily | binary or really anything to do with DST, That would be nice, but there's only so much that can be reasonably expected to be accomplished. How local time works is burned into many people's brains, and they simply cannot contemplate anything different as possible. They *know* how it works. End of discussion. | > tm_gmtoff and tm_zone - do you know what's going on there? | Added in https://www.austingroupbugs.net/view.php?id=1533 Ah yes, thanks, saved me looking it up. | See also https://www.austingroupbugs.net/view.php?id=1613 Only if you're really bored, that one is kind of obvious, and meaningless. I will also take this opportunity to correct an error I made in my previous message - issue 1619 (which has the TZ changes) isn't one of mine, and is entirely about that - what I was thinking of was 1614 (just change the number at the end of one of the URLs above) which is one of mine, and during the discussions of which (still ongoing, though that one I thought would have been the simplest one of the 1612/1613/1614 trilogy) the TZ issue arose, and led to 1619. kre
participants (4)
-
Brian Inglis -
Paul Eggert -
Robert Elz -
Steffen Nurpmeso