[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.BSM.4.64L.2403252321540.3887@herc.mirbsd.org>
Date: Mon, 25 Mar 2024 23:34:43 +0000 (UTC)
From: Thorsten Glaser <tg@...bsd.de>
To: musl@...ts.openwall.com
Subject: Re: Broken mktime calculations when crossing DST boundary
Alexander Weps dixit:
>And all of this works in glibc.
Not at all, glibc’s mktime just throws the towel with
EOVERFLOW saying that the requested time does not exist.
(It is only not permitted to change the input struct tm
member tm_wday if it returns EOVERFLOW but that doesn’t
mean that the output struct tm is correct.)
>> That’s because your application violates the constraints
>> that bind both, not just the libc, to the spec.
>
>Specify those constraints.
My wording here was badly, as dalias mentioned:
>It's not a constraint violation. mktime is required to accept inputs
>where the fields of the broken-down time don't fall within their
>respective ranges, and normalize them.
>
>Rather, the calling code is just making incorrect assumptions about
>the unspecified way that happens, […]
The “constraint” (wrong word) I meant was that your program
must not make assumptions about which of the two possible
conflict resolutions the libc chooses.
>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).
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.
