[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 24 Mar 2024 13:04:36 -0400
From: Rich Felker <dalias@...c.org>
To: Alexander Weps <exander77@...me>
Cc: Daniel Gutson <danielgutson@...il.com>, musl@...ts.openwall.com,
Markus Wichmann <nullplan@....net>
Subject: Re: Broken mktime calculations when crossing DST boundary
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
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.
