Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 26 Mar 2024 18:56:13 +0000
From: Alexander Weps <>
Subject: Re: Broken mktime calculations when crossing DST boundary

> > Show me a function implementation that produces same time next day
> > under this behavior you assume to be correct.
> It is not possible to do that with mktime. You’ll have to do
> that yourself. POSIX even says so.
> It does indicate that on implementations (their word for libcs
> here) that follow its recommendation to not normalise tm_sec,
> you can achieve the desired effect by adding 86400 to it, though
> that will not work right in the presence of a leap second on
> systems honouring them (which is a deviation from POSIX, of
> course).
> Adding 86400 to the time_t value, under the same leap second
> caveat, can work if your code can rely on POSIX (ISO C does not
> specify the internal structure of time_t).

Doesn't work, this will not give the same time next day, this fails on STD/DST changes.

Because same time next day is not always 86400 apart.

> bye,
> //mirabilos
> --
> 22:20⎜<asarch> The crazy that persists in his craziness becomes a master
> 22:21⎜<asarch> And the distance between the craziness and geniality is
> only measured by the success 18:35⎜<asarch> "Psychotics are consistently
> inconsistent. The essence of sanity is to be inconsistently inconsistent

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.