Package: tzdata Version: 2026b-0+deb13u1 Severity: important There's an issue with upstream tzdata 2026b that breaks date calculations with America/Vancouver. Observed in mailx, but there are probably other programs that do it. I haven't dug up just what's happening yet, but I'm working on that. In the meantime, what I see is that gmtime(3) returns the wrong data now if you're in America/Vancouver. As nothing should have changed for now (July) gmtime(3) should return the same data for today - the change takes effect in November:
/etc/localtime Sun Mar 8 09:59:59 2026 UT = Sun Mar 8 01:59:59 2026 PST
isdst=0 gmtoff=-28800
/etc/localtime Sun Mar 8 10:00:00 2026 UT = Sun Mar 8 03:00:00 2026 PDT
isdst=1 gmtoff=-25200
/etc/localtime Sun Nov 1 08:59:59 2026 UT = Sun Nov 1 01:59:59 2026 PDT
isdst=1 gmtoff=-25200
-/etc/localtime Sun Nov 1 09:00:00 2026 UT = Sun Nov 1 01:00:00 2026 PST
isdst=0 gmtoff=-28800
+/etc/localtime Sun Nov 1 09:00:00 2026 UT = Sun Nov 1 02:00:00 2026 MST
isdst=0 gmtoff=-25200
As it stands, mailx will issue the wrong time offset, which can be
problematic for things. An observed example involved monitoring emails
discarded because they were assumed to be over an hour old. The following
short program models what mailx does to calculate the date offset:
---------------------------------------------------------------------------
#include <stdio.h>
#include <time.h>
int main(int argc, char *argv[])
{
time_t t;
struct tm *tmptr;
int tzdiff, tzdiff_hour, tzdiff_min;
time(&t);
tmptr = localtime(&t);
tzdiff = t - mktime(gmtime(&t));
tzdiff_hour = (int)(tzdiff / 60);
tzdiff_min = tzdiff_hour % 60;
tzdiff_hour /= 60;
if (tmptr->tm_isdst > 0)
tzdiff_hour++;
printf("t (epoch seconds) is %d\n", t);
printf("mktime(gmtime(&t)) is %d\n", mktime(gmtime(&t)));
printf("t - mktime(gmtime(&t)) is %d\n", tzdiff);
printf("tzdiff_hour (that / 3600) is %d\n", tzdiff_hour);
printf("tm_isdst is %d\n", tmptr->tm_isdst);
printf("%+05d\n", tzdiff_hour * 100 + tzdiff_min);
}
---------------------------------------------------------------------------
To reproduce the issue, set your timezone to America/Vancouver, and run the
program. With tzdata_2026b, it will show an offset of -0600, which is
incorrect. It should be -0600, and it showed -0700 with tzdata_2026a. This
shows that gmtime(3) cares about the change in some detrimental way.
tzdata_2026b is current. 2026a can be found here - thanks NickH for
pointing me to it:
https://snapshot.debian.org/archive/debian/20260403T024139Z/pool/main/t/tzdata/tzdata_2026a-3_all.deb
It's also possible Java has problems with the new timezone, but I don't
have enough data to issue a report yet.
--
Mason Loring Bliss (( If I have not seen as far as others, it is because
[email protected] )) giants were standing on my shoulders. - Hal Abelson
signature.asc
Description: PGP signature
