On 2023-03-04 23:32, Robert Elz wrote:
Technically yes, but it is much harder to acquire access to old versions of POSIX standards than it is old RFCs, most people will just give up when all they find is the current one (whichever that is).
Although that used to be true, POSIX has gotten better. It's now no trouble to access older POSIX versions so long as you don't want to go back before 2001. For example, the previous (Issue 6, revised 2004) Open Group spec for POSIX can be read here: https://pubs.opengroup.org/onlinepubs/009695399/ and Internet RFC 8536, which contains a similar URL to point to a later POSIX edition, should be good for quite some time.
I was asking about any applications that are not implementations of that functionality - things that might not simply get updated if the TZif file format, were to alter
I'm afraid that I don't understand the premise of the question then. But it's not important. POSIX won't obsolete these TZ strings any time soon, and even if it does so (which in my view would be a mistake) those programs will still need to support those strings since they're required for TZif.
Anyone doing that is going to change the interpretation of all previous recorded timestamps to match the new rules.
Sure, but for many applications that's preferable to screwing up today's timestamps. There is no perfection in situations like these, only the best of unappetizing solutions. Lots of people would prefer having localtime work today, than to require users to run on UTC, even if this means some old timestamps are wrong by an hour (after all, that's better than their being wrong by *12* hours....). Again, I'm not recommending this over having a properly updated TZDB. Obviously the latter would be preferable. It's just that sometimes it's not feasible.
https://austingroupbugs.net/view.php?id=1639
now exists, and we will eventually get a resolution, one way or the other.
Thanks, I've followed up there.
| Glibc treats this same | example as specifying a 512-byte abbreviation for a time zone 4 hours | west of Greenwich.
... Why would they choose to ignore the max length limit
They don't ignore it. It's just that the upper bound is much bigger than the upper bound in tzcode/NetBSD.