On Mon, Aug 03, 2026 at 11:29:03PM -0500, Paul Eggert wrote: > The original bug report itself has serious bugs, but even the fixed test > program you supplied in > <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1143499#27> is wrong for > several reasons.
The code was taken more or less directly from mailx, incidentally. Mailx
says:
---------------------------------------------------------------------------
int
mkdate(FILE *fo, const char *field)
{
time_t t;
struct tm *tmptr;
int tzdiff, tzdiff_hour, tzdiff_min;
time(&t);
tzdiff = t - mktime(gmtime(&t));
tzdiff_hour = (int)(tzdiff / 60);
tzdiff_min = tzdiff_hour % 60;
tzdiff_hour /= 60;
tmptr = 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);
}
---------------------------------------------------------------------------
My reproducer says re-orders one thing - I set tmptr earlier - but I don't
see localtime(3) mutating what we pass it, so I figured that was safe:
---------------------------------------------------------------------------
#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);
}
---------------------------------------------------------------------------
But yeah, I'm convinced now. I'm going to submit a bug internally at Red
Hat and also to the upstream for mailx.
One lingering question remains, however.
I'd be grateful if someone could explain to me why we're seeing this today,
as my read of the change makes me think we shouldn't observe any change
*today* between timezones 2026a and 2026b.
PS: If anyone has any commentary here, please cc me directly, as while I'm
notionally subscribed to the list, so far I'm only seeing off-list copies
of replies, delivered directly.
--
Mason Loring Bliss [email protected] http://blisses.org/
For more enjoyment and greater efficiency, consumption is being standardized.
signature.asc
Description: PGP signature
