Re: [musl] Broken mktime calculations when crossing DST boundary

[Alexander Weps <exander77@pm.me>]

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@pm.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@libc.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