[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3yixwTENdfygkyC-VpJQ3EN-X6RgOM_A9EYuLzX0CgM_wOfDncIPUkyoj7RQkfdPk_IvYOo6gNwao8cHNiWkNoZoa8DhvJk3i0fYp1mC1fU=@pm.me>
Date: Sun, 24 Mar 2024 19:06:58 +0000
From: Alexander Weps <exander77@...me>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com, Daniel Gutson <danielgutson@...il.com>, Markus Wichmann <nullplan@....net>
Subject: Re: Broken mktime calculations when crossing DST boundary
I ran Asia/Omsk from 1900 to 2200 there and back again (59 seconds increments/decrements).
Everything ok in glibc.
Fails in musl very early:
1919-11-13 23:59:32 LMT
1919-11-13 23:54:01 LMT
No idea what is even happening there.
Glibc shows nothing interesting there:
1911-12-13 23:59:32 LMT
1911-12-14 00:00:31 LMT
???
AW
On Sunday, March 24th, 2024 at 19:36, Alexander Weps <exander77@...me> wrote:
> It is tiring, because you are not correct.
>
> You are also talking about a slightly different thing.
>
> If you have normalized time T1 in struct tm and you add something, normalize, you should always get normalized time T2, what is higher than T1.
> If you have normalized time T2 in struct tm and you subtract something, normalize, you should always get normalized time T1, which is lower than T2.
>
> I agree than for non normalized time (tm_isdst = -1 etc.) this would not apply. I agree that the decision how to deduce it is implementation specific and I don't really hold it against musl. I rewrote everything without tm_isdst = -1.
>
> But there cannot be a case where you have normalized time add something, normalize and create normalized time that is lower and vice versa.
>
> If you claim otherwise, provide counter example.
>
> I have done pretty extensive testing.
>
> AW
>
>
>
> On Sunday, March 24th, 2024 at 19:24, Rich Felker dalias@...c.org wrote:
>
> > On Sun, Mar 24, 2024 at 06:16:20PM +0000, Alexander Weps wrote:
> >
> > > > And subtracting seconds can't make time go forwards, but that's
> > > > what would happen with the alternate interpretation you want.
> > >
> > > That's just nonsense.
> > >
> > > I can go from 1900 to 2200 by adding seconds.
> > > And from 2200 to 1900 by subtracting seconds.
> > >
> > > I just did that using glibc.
> > >
> > > This is because each addition to struct tz fields leads to time
> > > going forward and each subtraction from struct tz fields leads to
> > > time going backwards.. As it should.
> > >
> > > There is clear ordering of struct tz contents.
> >
> > This is getting really tiring.
> >
> > In the presence of times which do not exist, the properties you want
> > are not mathematically consistent.
> >
> > EITHER you get cases where "start from time T, add something,
> > normalize" gives a broken-down time that looks like it's before T (but
> > isn't, because it's in a different zone rule),
> >
> > OR you get cases where "start from time T, subtract something,
> > normalize" gives a broken-down time that looks like it's after T (bit
> > isn't, because it's in a different zone rule).
> >
> > Preferring one of these nasty behaviors over the other is entirely
> > arbitrary.
> >
> > Time zones are nasty. Local time is nasty. If you want to do things
> > with it, you have to deal with that nastiness.
> >
> > 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.
