[Bug 297243] America/Vancounter PDT change in tzdata breaks gmtime(3)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D297243

            Bug ID: 297243
           Summary: America/Vancounter PDT change in tzdata breaks
                    gmtime(3)
           Product: Base System
           Version: 15.1-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: bin
          Assignee: [email protected]
          Reporter: [email protected]

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 PST
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>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
#include <time.h>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20

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 %ld\n", t);
    printf("mktime(gmtime(&t)) is %ld\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);
}=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20
---------------------------------------------------------------------------

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.

This is evidently an upstream issue, as it also affects RHEL, Debian, and
Fedora. I need to find the upstream and note it there.

--=20
You are receiving this mail because:
You are the assignee for the bug.=