Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 23 Mar 2024 11:59:56 +0000
From: Alexander Weps <>
To: Markus Wichmann <>
Subject: Re: Broken mktime calculations when crossing DST boundary

> You don't need to set yday or the others before calling mktime().

I thought that too, but wanted to test it on exactly the same struct tm. No change in behavior.

So I have found a minimal example:

void test()
    time_t t;
    struct tm tm = {0};
    char buf[64];

    tm.tm_year = 2024 - 1900;
    tm.tm_mon = 3 - 1;
    tm.tm_mday = 31;
    tm.tm_hour = 1;
    tm.tm_min = 59;
    tm.tm_sec = 2;

    strftime(buf, sizeof buf, "%F %T %Z", &tm);
    printf("before: %s\n", buf);
    tm.tm_isdst = -1; // This is the cause.
    tm.tm_min += 1;
    strftime(buf, sizeof buf, "%F %T %Z", &tm);
    printf("after: %s\n", buf);

Setting tm_isdst to -1 after first mktime and before second mktime causes the issue.


On Saturday, March 23rd, 2024 at 11:38, Markus Wichmann <> wrote:

> Am Sat, Mar 23, 2024 at 09:26:00AM +0000 schrieb Alexander Weps:
> > This works for me as well even after changes to match struct tm in my
> > app (setting tm_yday, __tm_gtmoff a __tm_zone):
> You don't need to set yday or the others before calling mktime().
> mktime() is defined to only use year, mon, mday, hour, min, sec, and
> isdst as input, normalize them, and calculate the others (and also the
> UNIX time stamp).
> > Any idea how could a previous calculation mess with musl internals so
> > it would start producing bad results? Because otherwise, I don't see
> > how this could be happening if you completely extract it out of the
> > code and it works.
> The only thing that means is that the isolated code works, and the bug
> is elsewhere. I'm sorry, but you are going to have to debug this
> yourself. There may be some static memory getting corrupted (e.g. the TZ
> and rule caches), but honestly this is just speculation.
> > And when I compile under glibc, everything is fine.
> That tends to indicate some undefined behavior. Not that that helps you
> find the reason. You are going to have to debug it. Finding a minimum
> reproducer may help in that, or you directly apply liberal amounts of
> gdb.
> You seem to have dropped the list from CC, so I'm adding it back.
> Ciao,
> Markus

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.