[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 24 Mar 2024 19:13:18 +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
Sorry, found it, looked at wrong date in glibc:
So Asia/Omsk:
So glibc is:
1919-11-13 23:59:23 LMT
1919-11-14 00:06:52 +05
And musl is:
1919-11-13 23:59:32 LMT
1919-11-13 23:54:01 LMT
AW
On Sunday, March 24th, 2024 at 20:06, Alexander Weps <exander77@...me> wrote:
> 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.
