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 02:45:00 +0000
From: Alexander Weps <>
Subject: Re: Broken mktime calculations when crossing DST boundary

On Wednesday, March 27th, 2024 at 02:35, Thorsten Glaser <> 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.