[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 24 Mar 2024 18:16:20 +0000
From: Alexander Weps <exander77@...me>
To: musl@...ts.openwall.com
Cc: Daniel Gutson <danielgutson@...il.com>, Markus Wichmann <nullplan@....net>
Subject: Re: Broken mktime calculations when crossing DST boundary
> 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.
AW
On Sunday, March 24th, 2024 at 19:02, Rich Felker <dalias@...c.org> wrote:
> On Sun, Mar 24, 2024 at 05:12:35PM +0000, Alexander Weps wrote:
>
> > Adding seconds cannot make time go backwards. If that is how it was
> > interpreted, than the interpretation is erroneous.
>
>
> And subtracting seconds can't make time go forwards, but that's what
> would happen with the alternate interpretation you want.
>
> There is fundamentally no way for the interface to read your mind and
> know that the time you requested is "move forward from a past valid
> normalized time" and not "move backward from a future valid normalized
> time".
>
> 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.
