Re: [musl] Broken mktime calculations when crossing DST boundary

[Alexander Weps <exander77@pm.me>]

> 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;
    print_tm(&tm);

    mktime(&tm);
    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;
    mktime(&tm);
    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.

AW


On Saturday, March 23rd, 2024 at 11:38, Markus Wichmann <nullplan@gmx.net> 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