[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0_9-JV2MW3avVvzhE9vjqKqCX0fEZy0uUuZKIohFGEFDBY912nwZyxZe560H0cf_b8L2gD8e0eUAUp2Q3e1rmra3XEppx9HPhhFeulwLYZA=@pm.me>
Date: Sun, 24 Mar 2024 17:12:35 +0000
From: Alexander Weps <exander77@...me>
To: musl@...ts.openwall.com
Cc: Daniel Gutson <danielgutson@...il.com>, Markus Wichmann <nullplan@....net>
Subject: Re: Broken mktime calculations when crossing DST boundary
Adding seconds cannot make time go backwards. If that is how it was interpreted, than the interpretation is erroneous.
I think I will do some test.
If you start with 1900-01-01 00:00:00 and start adding seconds and calling mktime, you should reliable get to 2200-12-31 59:59:59 in all timezones. Same goes for minutes, hours, days, years.
If that's not the case then the interpretation in musl is wrong.
This is a basic elementary functionality of mktime.
There can't be any going back in time a cycles.
AW
On Sunday, March 24th, 2024 at 18:04, Rich Felker <dalias@...c.org> wrote:
> 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.
