[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 27 Mar 2024 01:35:47 +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:
>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.
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.
