[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 23 Mar 2024 08:31:48 -0400
From: Rich Felker <dalias@...c.org>
To: Alexander Weps <exander77@...me>
Cc: Markus Wichmann <nullplan@....net>, musl@...ts.openwall.com
Subject: Re: Broken mktime calculations when crossing DST boundary
On Sat, Mar 23, 2024 at 12:00:52PM +0000, Alexander Weps wrote:
> This is how it should work as far as I am concerned. After
> manipulating the date, the tm_isdst is set to -1.
>
> >From https://cplusplus.com/reference/ctime/tm/:
This site is notoriously sloppy if not outright wrong about pretty
much everything.
> The Daylight Saving Time flag (tm_isdst) is greater than zero if
> Daylight Saving Time is in effect, zero if Daylight Saving Time is
> not in effect, and less than zero if the information is not
> available.
The actual specification is at
https://pubs.opengroup.org/onlinepubs/9699919799/functions/mktime.html
(POSIX version; the C version is not independently linkable but says
basically the same thing anyway). The relevant text, which differs
from the above, is:
"A negative value for tm_isdst shall cause mktime() to attempt to
determine whether Daylight Savings Time is in effect for the
specified time."
No details are specified for how this determination is made, so it may
differ between implementations. At DST transition boundaries, it's
impossible to define unambiguously. There are either times that don't
exist, or that could mean two different things.
If there are cases where our current behavior isn't *consistent* (the
input time does not match the output in either DST or non-DST), it
seems like those should be treated as bugs and fixed. But if you're
just expecting the implementation to guess whether your nonexistant
time came from moving forward from non-DST or backward from DST, it
can't; it just had to make an arbitrary choice, and that choice is not
going to agree across different systems.
> And the date should be correctly set as DST or STD in mktime.
>
> I have a date. I make change in fields, I set tm_isdst = -1, I call
> mktime.
If you already have a date and want a new date offset by some fixed
amount of time from it, setting tm_isdst is wrong. You leave tm_isdst
alone and adjust whichever field(s) (e.g. tm_min) you want to offset
by, then call mktime. The resulting tm_isdst (and correspondingly
other fields) may have changed if you crossed a DST boundary by making
the offset.
When you set tm_isdst=-1, you're throwing away information and
explicitly asking the implementation to guess what an ambiguous
timestamp meant.
Does this help? Do you think there's an actual bug to be investigated
on our side here?
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.
