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

[Rich Felker <dalias@libc.org>]

On Sun, Mar 24, 2024 at 01:36:42PM +0000, Alexander Weps wrote:
> Also thanks for the Pacific/Apia example. Not only that it fails for that date:
> Pattern: * * * * * *
> Initial: 2011-12-29_23:59:59
> Expected: 2011-32-31_00:00:00
> Actual: 2011-12-29_00:00:00
> My cron tool again going back in time.
> 
> It fails one other test.
> 
> I have to run my tests on multiple timezones.
> 
> And it works in glibc.
> 
> And that's after I removed tm_isdst and rewrote half the code to accommodate.
> 
> Can We agree on some simple premise that with no uncertain STD/DST
> settings (tm_isdst = 0 or tm_isdst = 1), incrementing seconds by 1
> and calling mktime should never cause time to go back?
> 
> Well, behold Pacific/Apia:
> 
> I set 2011-12-29 23:59:59:
> 
> tm_sec: 59
> tm_min: 59
> tm_hour: 23
> tm_mday: 29
> tm_mon: 11
> tm_year: 111
> tm_wday: 0
> tm_yday: 0
> tm_isdst: 1
> tm_gmtoff: 0
> tm_zone: (null)
> 
> Calling mktime to see if everything is correct:
> mktime(&tm);
> 
> before: 2011-12-29 23:59:59 -10
> tm_sec: 59
> tm_min: 59
> tm_hour: 23
> tm_mday: 29
> tm_mon: 11
> tm_year: 111
> tm_wday: 4
> tm_yday: 362
> tm_isdst: 1
> tm_gmtoff: -36000
> tm_zone: -10
> 
> Incrementing seconds and calling mktime:
> tm.tm_sec += 1;
> mktime(&tm);
> 
> after: 2011-12-29 00:00:00 -10
> tm_sec: 0
> tm_min: 0
> tm_hour: 0
> tm_mday: 29
> tm_mon: 11
> tm_year: 111
> tm_wday: 4
> tm_yday: 362
> tm_isdst: 1
> tm_gmtoff: -36000
> tm_zone: -10
> We went from:
> 2011-12-29 23:59:59 -10
> To:
> 2011-12-29 00:00:00 -10
> 
> By adding 1 second. The tm_isdst was not set to -1.
> 
> This is totally unreliable.

From what I understand, you've set the input to a time that doesn't
exist in the local timezone: 2011-12-30 00:00:00. This could be either
1 second after 2011-12-29 23:59:59, as you intended, or 1 day before
2011-12-31 00:00:00. The latter is how it was interpreted. However, it
does not seem to have correctly set tm_gmtoff to reflect how it was
interpreted. We should check this out because that's probably an
actual bug.

Rich