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?