[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 24 Mar 2024 14:24:59 -0400
From: Rich Felker <dalias@...c.org>
To: Alexander Weps <exander77@...me>
Cc: musl@...ts.openwall.com, Daniel Gutson <danielgutson@...il.com>,
Markus Wichmann <nullplan@....net>
Subject: Re: Broken mktime calculations when crossing DST boundary
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.
