[tz] Tzdb and the Sunshine Protection Act

[Paul Eggert]

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.