[tz] Weird PST8PDT and EST5EDT behavior on Alpine Linux

[Paul Eggert]

On 2024-03-03 22:51, Russ Allbery via tz wrote:
> This probably belongs on an Alpine-specific mailing list, but this was odd
> enough that I'm wondering if I'm missing something about the
> interpretation of legacy POSIX time zone strings....
> $ env TZ=PST8PDT date -R -d @1643145780
> Tue, 25 Jan 2022 14:23:00 -0700

That's not a POSIX time zone setting. However as you noted, "PST8PDT" is 
a TZDB Zone (this is for compatibility with pre-POSIX systems), so this 
smells like a bug in how musl interprets TZif files.


> Why would the system decide that time stamp should use daylight saving
> time?

A possible problem is that musl is not correctly interpreting the TZ 
string at the end of the TZif file. If the last explicit transition in 
the TZif file is to DST, and if the TZ string is ignored or mishandled, 
you'll get wrong answers such as the ones you described.


> The Alpine Linux system in question does have PST8PDT and EST5EDT files in
> /usr/share/zoneinfo.  The Olson time zone identifiers do work as expected:
> 
> $ env TZ=America/Los_Angeles date -R -d @1643145780
> Tue, 25 Jan 2022 13:23:00 -0800
> $ env TZ=America/New_York date -R -d @1643145780
> Tue, 25 Jan 2022 16:23:00 -0500

That's odd. Perhaps the PST8PDT file is not actually being consulted? 
(You can use strace to tell.) Or the PST8PDT file is slim but the 
Los_Angeles file is fat? (Here I'm talking about zic's -b option.) That 
could also explain the problem, as fat files have explicit transitions 
out through the year 2037 so this would work around any bug in parsing 
the POSIX TZ string embedded at the end of the TZif file. You can test 
this hypothesis by trying dates 100 years in the future.