Hi, all. I saw an issue through work with the new America/Vancouver PDT/MST, and it affects everything with tzdata 2026b - I checked RHEL 8, 9, 10, and Fedora. Then I checked Debian and FreeBSD, and they all behave the same way, which surprised me.
In short, the new timezone line is breaking the timezone offset
calculations gmtime(3) is doing, despite our not actually being in November
yet. I haven't yet read through gmtime(3) to understand the mechanism, but
it doesn't have to be gated on me, so I opened up a couple bugs, and then
found this list. Here are the bugs I opened. They include a short program
modelled on how mailx(1) calculates the date offset, which illustrates the
error:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1143499
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=297243
The two things that make me curious:
1. Why's this matter today when the diff I see from zdump doesn't take
effect until November?
2. This shows up with mailx, it might show up in Java, and I bet there are
other things out there that use this mechanism for calculating offsets.
Also, if you swap back and forth between tzdata 2026 a and b, the behavior
appears reliably with b, with nothing else changing. So what's the right
fix for that? I haven't tested this yet but my off the cuff thought was,
"they're moving to permanent daylight savings time - why is DST not flagged
as being on in the new zone file line?" But without more context and
familiarity with the code, I can imagine that having bad consequences in
other situations.
--
Mason Loring Bliss [email protected] Ewige Blumenkraft!
(if awake 'sleep (aref #(sleep dream) (random 2))) -- Hamlet, Act III, Scene I
signature.asc
Description: PGP signature
