Bug#1143499: America/Vancounter PDT change in tzdata breaks gmtime(3)

--7QOiWwEqXOULX/sJ
Content-Type: text/plain; protected-headers=v1; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Mon, 3 Aug 2026 00:55:44 -0400
From: Mason Loring Bliss <[email protected]>
To: [email protected]
Subject: America/Vancounter PDT change in tzdata breaks gmtime(3)

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 =3D Sun Mar  8 01:59:59 2026 PS=
T isdst=3D0 gmtoff=3D-28800
 /etc/localtime  Sun Mar  8 10:00:00 2026 UT =3D Sun Mar  8 03:00:00 2026 P=
DT isdst=3D1 gmtoff=3D-25200
 /etc/localtime  Sun Nov  1 08:59:59 2026 UT =3D Sun Nov  1 01:59:59 2026 P=
DT isdst=3D1 gmtoff=3D-25200
-/etc/localtime  Sun Nov  1 09:00:00 2026 UT =3D Sun Nov  1 01:00:00 2026 P=
ST isdst=3D0 gmtoff=3D-28800
+/etc/localtime  Sun Nov  1 09:00:00 2026 UT =3D Sun Nov  1 02:00:00 2026 M=
ST isdst=3D0 gmtoff=3D-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 =3D localtime(&t);

    tzdiff =3D t - mktime(gmtime(&t));

    tzdiff_hour =3D (int)(tzdiff / 60);
    tzdiff_min =3D tzdiff_hour % 60;
    tzdiff_hour /=3D 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.

--=20
Mason Loring Bliss  ((   If I have not seen as far as others, it is because
 [email protected]   ))   giants were standing on my shoulders. - Hal Abels=
on

--7QOiWwEqXOULX/sJ
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEEXtBZz1axB5rEDCEnrJXcHbvJVUFAmpwH1EACgkQnrJXcHbv
JVXM5Q//Rx4CAkJc4TTFrstX/xlrIcYEzHAhMexRHcMoQF4RjAHYm6SUr85Jknd4
nK6jGK6njnoXrYNe+vvf+UPu8WXV+zvnrmwOaPqz/oNeIno4G1MKibE8i3h37O8d
sFWm7eUWZmxtRxwJAkV7pxnoWiRj2jVbK4NfYTY+bmhhPJrUVnRKhStE96yX6cb4
JszpaGWypD7vbH01JrumsM2/HmRvEzDAQFw4S6R9LR3+P7l83vzyZ2kOnyc4/ESM
Y3LTuBjoSb1GyOwUPDOZFrXAJoIXVTKgDB53//FXHuVWp/4bMxZ7BTTRUMjKk5sM
f2FCJNMloSooVWKKnkTm26XOpUQP6Fr7z6Pkm8LZuuLkADooHJLPTsK5rEQDQeI/
FSZDHD8/SmH/5gXdG9iagXdyifoOrjSaYDDVo62TUUWY1rpH4Yoh6UVTqBDF1h4n
+TqbiSivbwPm1ygm4GfKB92MZdLnsutW3XshOJNVquJgNUgtzuFVN5vMO7cvIfKr
GwiQvt+xSC+48c5vjxMeiVv5KXhZ1h3Nr8VkrExwjmM1xNJHdZ1qp8TAW60/BwhM
hwK18yG5WMm39OrGS55o3z4/Um1yuAkji96+MygPp/rh21DIviwALfD2bp/hBbB7
8FJ4v7GtVsufKWHihOG6yI6Ydqd1SqH63oDHSrwOsjubLj93TiM=
=iaMs
-----END PGP SIGNATURE-----

--7QOiWwEqXOULX/sJ--