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

[Alexander Weps <exander77@pm.me>]

This is how it should work as far as I am concerned. After manipulating the date, the tm_isdst is set to -1.

From https://cplusplus.com/reference/ctime/tm/:
The Daylight Saving Time flag (tm_isdst) is greater than zero if Daylight Saving Time is in effect, zero if Daylight Saving Time is not in effect, and less than zero if the information is not available.

And the date should be correctly set as DST or STD in mktime.

I have a date. I make change in fields, I set tm_isdst = -1, I call mktime.

I see only on place where tm_isdst is checked and that's:
time_t mktime(struct tm *tm)
{
    struct tm new;
    long opp;
    long long t = __tm_to_secs(tm);

    __secs_to_zone(t, 1, &new.tm_isdst, &new.__tm_gmtoff, &opp, &new.__tm_zone);

    if (tm->tm_isdst>=0 && new.tm_isdst!=tm->tm_isdst)
        t -= opp - new.__tm_gmtoff;

    t -= new.__tm_gmtoff;
    if ((time_t)t != t) goto error;

    __secs_to_zone(t, 0, &new.tm_isdst, &new.__tm_gmtoff, &opp, &new.__tm_zone);

    if (__secs_to_tm(t + new.__tm_gmtoff, &new) < 0) goto error;

    *tm = new;
    return t;

error:
    errno = EOVERFLOW;
    return -1;
}

So tm->tm_isdst>=0 seems to be the cause here.

AW

On Saturday, March 23rd, 2024 at 13:00, Alexander Weps <exander77@pm.me> wrote:

> > 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