[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 27 Mar 2024 02:45:00 +0000
From: Alexander Weps <exander77@...me>
To: musl@...ts.openwall.com
Subject: Re: Broken mktime calculations when crossing DST boundary
On Wednesday, March 27th, 2024 at 02:35, Thorsten Glaser <tg@...bsd.de> wrote:
> Alexander Weps dixit:
>
> > But mktime can return -1 if and when it deems that struct tm cannot be
> > represented in epoch seconds.
>
>
> But it CAN be represented in epoch seconds.
>
> It can only not be represented in epoch seconds if it’s
> outside of the range of time_t, e.g. [LONG_MIN; LONG_MAX].
>
> POSIX even explicitly documents how these discontinuities
> are mapped, which I already quoted:
>
> | If a geographical timezone changes its UTC offset such that “old
> | 00:00” becomes “new 00:30” and mktime() is given 00:20, it treats that
> | as either 20 minutes after “old 00:00” or 10 minutes before “new
> | 00:30”, and gives back appropriately altered struct tm fields.
Provide source.
>
> This makes it clear that there are two ways the struct tm can
> be represented in time_t, and that the implementation must
> choose one of them.
>
> bye,
> //mirabilos
> --
> [...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but
> what about xfs, and if only i had waited until reiser4 was ready... in the be-
> ginning, there was ffs, and in the middle, there was ffs, and at the end, there
> was still ffs, and the sys admins knew it was good. :) -- Ted Unangst über *fs
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.
