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.