[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4YlR0YRqzZlDIOVv6SP8UDoop89n8u7BvQl_7eXNTvDZnogXMxG1z-TLGIBf-O4edUphddXGfADbk_d7Uzb37g5JoH7vOIvvNRMFDxPWZok=@pm.me>
Date: Mon, 25 Mar 2024 00:36:49 +0000
From: Alexander Weps <exander77@...me>
To: musl@...ts.openwall.com
Subject: Re: Broken mktime calculations when crossing DST boundary
I have no problem with the POSIX (Issue 8) or ISO C standard.
I agree it doesn't mandate mktime making correct calculations, but I would assume it is expected.
AW
On Monday, March 25th, 2024 at 00:51, Thorsten Glaser <tg@...bsd.de> wrote:
> Alexander Weps dixit:
>
> > You are describing the musl behavior, more specifically what I see in mktime & __tm_to_secs.
> > I don't think this is correct behavior.
>
>
> This is what POSIX (Issue 8) and AFAIR also the next ISO C standard
> mandate, though:
>
> 1.–6. struct tm is normalised from seconds or minutes up to year
> 7. struct tm is converted to time_t (wrongly written down as
> “the number of seconds since the epoch” as it omits leap
> seconds)
> 8. timezone corrections for standard time at the moment in
> time calculated in step 7 is applied
> 9. if the timezone has DST:
> + if tm_isdst is positive, the time is adjusted by the offset
> + if tm_isdst is negative, the result is either the same as
> if it were 0 or the same as if it were 1; if the struct tm
> specifies a gap or repeated segment, which of the two is
> used is explicitly unspecified, i.e. the caller cannot rely
> on the libc to guess his intent if he sets tm_isdst to -1.
> 10. (not numbered) for gaps or repeats, mktime uses either the value
> from before the gap/repeat or the one after, choice again
> unspecified
>
> Tough luck there.
>
> The wording in this part is interesting though:
>
> | If tm_isdst is positive, mktime() shall further adjust the seconds
> | since the Epoch by the DST offset.
>
> But I guess that if you call with tm_isdst=1 and a broken-down time
> that clearly corresponds to nōn-DST, the DST offset for it is just 0
> and it’ll work out the obvious way.
>
> bye,
> //mirabilos
> --
> “It is inappropriate to require that a time represented as
> seconds since the Epoch precisely represent the number of
> seconds between the referenced time and the Epoch.”
> -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2
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.
