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