[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 26 Mar 2024 18:56:13 +0000
From: Alexander Weps <exander77@...me>
To: musl@...ts.openwall.com
Subject: Re: Broken mktime calculations when crossing DST boundary
>
> > Show me a function implementation that produces same time next day
> > under this behavior you assume to be correct.
>
>
> It is not possible to do that with mktime. You’ll have to do
> that yourself. POSIX even says so.
>
> It does indicate that on implementations (their word for libcs
> here) that follow its recommendation to not normalise tm_sec,
> you can achieve the desired effect by adding 86400 to it, though
> that will not work right in the presence of a leap second on
> systems honouring them (which is a deviation from POSIX, of
> course).
>
> Adding 86400 to the time_t value, under the same leap second
> caveat, can work if your code can rely on POSIX (ISO C does not
> specify the internal structure of time_t).
Doesn't work, this will not give the same time next day, this fails on STD/DST changes.
Because same time next day is not always 86400 apart.
>
> bye,
> //mirabilos
> --
> 22:20⎜<asarch> The crazy that persists in his craziness becomes a master
>
> 22:21⎜<asarch> And the distance between the craziness and geniality is
>
> only measured by the success 18:35⎜<asarch> "Psychotics are consistently
>
> inconsistent. The essence of sanity is to be inconsistently inconsistent
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.
