Your message dated Wed, 5 Aug 2026 18:37:48 +0200 with message-id <[email protected]> and subject line Re: Bug#1143499: America/Vancounter PDT change in tzdata breaks gmtime(3) has caused the Debian Bug report #1143499, regarding mktime() heuristics fail with the America/Vancouver change to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 1143499: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1143499 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---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
--- End Message ---
--- Begin Message ---Hi, On 2026-08-03 23:42, Aurelien Jarno wrote: > control: reassign -1 libc6/2.36-9 > control: retitle -1 mktime() heuristics fail with the America/Vancouver change > control: severity -1 normal > > Hi, > > On 2026-08-03 00:55, Mason Loring Bliss wrote: > > 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: > > The change is actually causing the mktime() heuristics in glibc to fail, > it's not linked to gmtime(3). But the code you submitted is also buggy. > > > /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)); > > The main issue is there. gmtime() returns a tm structure with tm_isdst > set to 0, which is not correct as the time (at least when executed > currently) includes a DST. With the previous tzdata version, the > mktime heuristics were able to fix it, but it is not the case anymore for > dates after 2026-06-06). It is not clear yet why. Upstream said [1] this actually works as expected, see: [1] https://sourceware.org/bugzilla/show_bug.cgi?id=34480 So the remaining issue is due to the bugs in the code you submitted. I am therefore closing the bug. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B [email protected] http://aurel32.net
Description: PGP signature
--- End Message ---
