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

--WbzIbrYAww4Z3tHB
Content-Type: text/plain; protected-headers=v1; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Mon, 3 Aug 2026 18:13:55 -0400
From: Mason Loring Bliss <[email protected]>
To: Aurelien Jarno <[email protected]>
Cc: [email protected]
Subject: Re: Bug#1143499: America/Vancounter PDT change in tzdata breaks
 gmtime(3)

On Mon, Aug 03, 2026 at 11:42:16PM +0200, Aurelien Jarno wrote:

> The change is actually causing the mktime() heuristics in glibc to fail,=
=20
> it's not linked to gmtime(3). But the code you submitted is also buggy.

Ah, hm. Thank you for the clarification.


> >     tzdiff =3D t - mktime(gmtime(&t));
>=20
> The main issue is there. gmtime() returns a tm structure with tm_isdst=20
> set to 0, which is not correct as the time (at least when executed=20
> currently) includes a DST.

Alright. For what it's worth, I tried to copy this with as little
modification as possible from Heirlom mailx, as shipped by RHEL. I don't
see equiovalent functionality in bsd-mailx. Here's the code, which RHEL
doesn't patch, so this is unmodified upstream:

/*
 * Create a Date: header field.
 * We compare the localtime() and gmtime() results to get the timezone,
 * because numeric timezones are easier to read and because $TZ is
 * not set on most GNU systems.
 */
int
mkdate(FILE *fo, const char *field)
{
        time_t t;
        struct tm *tmptr;
        int tzdiff, tzdiff_hour, tzdiff_min;

        time(&t);
        tzdiff =3D t - mktime(gmtime(&t));
        tzdiff_hour =3D (int)(tzdiff / 60);
        tzdiff_min =3D tzdiff_hour % 60;
        tzdiff_hour /=3D 60;
        tmptr =3D localtime(&t);
        if (tmptr->tm_isdst > 0)
                tzdiff_hour++;
        return fprintf(fo, "%s: %s, %02d %s %04d %02d:%02d:%02d %+05d\n",
                        field,
                        weekday_names[tmptr->tm_wday],
                        tmptr->tm_mday, month_names[tmptr->tm_mon],
                        tmptr->tm_year + 1900, tmptr->tm_hour,
                        tmptr->tm_min, tmptr->tm_sec,
                        tzdiff_hour * 100 + tzdiff_min);
}



> The correct way is to force tm_isdst to -1, which ensure that the DST is
> determined by mktime(). This will also work correctly with the POSIX 2024
> version of mktime, which forbids applying any heuristics if tm_isdst is 0=
 or 1
> (the behaviour was not fully clear for earlier POSIX versions).

Alright, that's interesting. I've pointed the IANA list to this bug, and if
there's additional discussion there I'll refresh my pointer. Thank you.


> The following updated code should work in all cases:

Useful. I'll figure out how to submit an upstream bug for Heirloom mailx,
I'll point them here, and then I'll point the Red Hat maintainers to the
upstream bug.

I'll still be quite interested in what's making glibc mktime(3) fail,
espeically given that FreeBSD seems to fail similarly.

Thank you again.

--=20
Mason Loring Bliss      "What diabolical chicken stepped on your
 [email protected]          forehead and sat on your chin?"

--WbzIbrYAww4Z3tHB
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAEBCgAdFiEEEXtBZz1axB5rEDCEnrJXcHbvJVUFAmpxEqMACgkQnrJXcHbv
JVUw+RAAwvVVpo2b1LVNfr3HsrvTTk2KVt1kaq8gKCYEPAxsEzIytGErp7e8UeDA
LGYcG3UY4sD717NYRKkeuDNHNNxVutRXttDdxX7IiqmSONzNaUwv4+eNfuF+Be4S
tUehWfbxN6zygIcirHFltz1Ul409bWkODGJJWIgtRosl5DJ/sfQ+NIBqqeIKpNdJ
r4iIqVcCs1saMT0cAT/lET2noofZAKEuH4+HhIKxmn/yDi4a5KiTLOcufPOghX60
GCCZWtIL9w0PACppcwjdyIUrsr39XiBkRBSH7t/fAJA39Wv+bKkqDC2QEYi8qoQU
Fg2daceUJ6n/YefXA8mNSOrEa3HCkoGGoelJ53/lly6RxMEQVpva0arwt+iNfyIS
BhtT3ayUqBq44fpS80Sf5HwatC1eWMZcN37EzbTAZM7f41FVFH4oMm3wBl+n2/gL
E2hCkA9qvxwC7MntX88r4MpUL3ZMx+jhs/GsVwpU5W8xZ7w4c+5AQvLOywZl30YN
28tFRMcEhU3v27J5+LYuVtxETLWhx0vqzngkqOjtmmmCpzF9JU5v9D7e4oO/BmpQ
Q5FogKNTX4E1acuzKZ3qXrCZNbVI0MQRQxWuL4RqJR2zs4LIZCiNboLSbu0GmabK
VHf5+sCmCjNlpp7tpe1sUoq/mw2HsBBNDFIr4d/DupD2GjJNglU=
=bz/w
-----END PGP SIGNATURE-----

--WbzIbrYAww4Z3tHB--