Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 27 Mar 2024 01:35:47 +0000 (UTC)
From: Thorsten Glaser <>
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.

[...] 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.