[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <l1V8rm469ESVLMY_Ar0Q-_PAEcLsbFfUYW1-CQcDL2yx_u3afuSt1kX1IYPPeekzIAD2bpvKQ2_NYXWin6HWZ-F9jjiY6W7mdEF00E0VOiQ=@pm.me>
Date: Mon, 25 Mar 2024 22:59:57 +0000
From: Alexander Weps <exander77@...me>
To: musl@...ts.openwall.com
Subject: Re: Broken mktime calculations when crossing DST boundary
See below.
AW
On Monday, March 25th, 2024 at 23:40, Thorsten Glaser <tg@...bsd.de> wrote:
> Alexander Weps dixit:
>
> > On Monday, March 25th, 2024 at 13:21, Rich Felker dalias@...c.org wrote:
> >
> > > On Mon, Mar 25, 2024 at 11:52:00AM +0000, Alexander Weps wrote:
>
> > > > Musl cannot reliably increment date by a day. Incrementing struct tm
> > > > representing 2011-12-29 01:00:00 -10 by one day leads to the same
> > > > date.
>
>
> No, that’s correct.
>
> Your chosen timezone has a discontinuity:
>
> $ TZ=Pacific/Apia date -d @1325239199
> Thu Dec 29 23:59:59 -10 2011
> $ TZ=Pacific/Apia date -d @1325239200
> Sat Dec 31 00:00:00 +14 2011
>
> This means any time between this simply does not exist
> in broken-down time.
I am not calculating any time between.
I am using struct tm and mktime to calculated a date with specific offset from initial date.
When I add 1 to tm_sec it means I am calculating a date that is one second after the initial date.
And all of this works in glibc.
Is the argument that glibc being able to do basic struct tm calculations is an incorrect behavior?
>
> > > > Causing a program to loop or stack overflow.
>
>
> That’s because your application violates the constraints
> that bind both, not just the libc, to the spec.
Specify those constraints.
>
> > Output from musl:
> >
> > 2011-12-29 01:00:00 -10
> >
> > tm.tm_mday += 1;
> > t = mktime(&tm);
> >
> > 2011-12-29 01:00:00 -10 <-- date is the same after incrementing
>
>
> This is… not as incorrect as you state.
>
> The steps here are:
>
> • 2011-12-30 01:00:00 ← input
> • 2011-12-30 01:00:00 ← input after normalisation (!)
> • conversion to time_t (1325206800), application of timezone offset
> • detection of the discontinuity between 2011-12-29 23:59:59 and
> 2011-12-31 00:00:00
> • arbitrary choice of selecting either endpoint
>
> tbh I’d expect this to end up in 1325239199=2011-12-29 23:59:59
> instead of 2011-12-29 01:00:00 though, at least from reading the
> latest Issue 8 proofreading draft. WDYT dalias?
>
> > tm.tm_mday -= 1;
> > t = mktime(&tm);
> >
> > 2011-12-28 01:00:00 -10 <-- going below the original date while decrementing
>
>
> This is entirely correct, again. You’re starting from
> 2011-12-28 01:00:00, you’re getting it back.
Show me a function implementation that produces same time next day under this behavior you assume to be correct.
>
> bye,
> //mirabilos
> --
> “It is inappropriate to require that a time represented as
> seconds since the Epoch precisely represent the number of
> seconds between the referenced time and the Epoch.”
> -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2
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.
