[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9c2qfe36CoPBfKjzn1lDDZ_hfyNJCZW6-6ZTZlQgHAPr2djicIMMweEqUoQoQsDWsBt4AAZBL8vZlcsVCL950rYhcPpMDvhzDWean3oVHbs=@pm.me>
Date: Sun, 24 Mar 2024 18:36:40 +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
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.
