[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <k-ThelZ9H3lbpQTYR4-HcBxsI_dzqStE-6fmE2NXSegDpA8u_c1KoRMWBhBu0Q5phyH67pQtbJ1x6qTEwnwpcY_ln1G1vI85TFOqbqlk4zE=@pm.me>
Date: Sun, 24 Mar 2024 13:36:42 +0000
From: Alexander Weps <exander77@...me>
To: Daniel Gutson <danielgutson@...il.com>
Cc: musl@...ts.openwall.com, Markus Wichmann <nullplan@....net>
Subject: Re: Broken mktime calculations when crossing DST boundary
Also thanks for the Pacific/Apia example. Not only that it fails for that date:
Pattern: * * * * * *
Initial: 2011-12-29_23:59:59
Expected: 2011-32-31_00:00:00
Actual: 2011-12-29_00:00:00
My cron tool again going back in time.
It fails one other test.
I have to run my tests on multiple timezones.
And it works in glibc.
And that's after I removed tm_isdst and rewrote half the code to accommodate.
Can We agree on some simple premise that with no uncertain STD/DST settings (tm_isdst = 0 or tm_isdst = 1), incrementing seconds by 1 and calling mktime should never cause time to go back?
Well, behold Pacific/Apia:
I set 2011-12-29 23:59:59:
tm_sec: 59
tm_min: 59
tm_hour: 23
tm_mday: 29
tm_mon: 11
tm_year: 111
tm_wday: 0
tm_yday: 0
tm_isdst: 1
tm_gmtoff: 0
tm_zone: (null)
Calling mktime to see if everything is correct:
mktime(&tm);
before: 2011-12-29 23:59:59 -10
tm_sec: 59
tm_min: 59
tm_hour: 23
tm_mday: 29
tm_mon: 11
tm_year: 111
tm_wday: 4
tm_yday: 362
tm_isdst: 1
tm_gmtoff: -36000
tm_zone: -10
Incrementing seconds and calling mktime:
tm.tm_sec += 1;
mktime(&tm);
after: 2011-12-29 00:00:00 -10
tm_sec: 0
tm_min: 0
tm_hour: 0
tm_mday: 29
tm_mon: 11
tm_year: 111
tm_wday: 4
tm_yday: 362
tm_isdst: 1
tm_gmtoff: -36000
tm_zone: -10
We went from:
2011-12-29 23:59:59 -10
To:
2011-12-29 00:00:00 -10
By adding 1 second. The tm_isdst was not set to -1.
This is totally unreliable.
AW
On Sunday, March 24th, 2024 at 12:05, Alexander Weps <exander77@...me> wrote:
> My head cannon for Israeli-Palestinian war is that it's a war about superiority of ones timezone.
>
> Single region, two timezone, two different DST changes. Depending on your nationality, you have different timezone, your job may have different timezone, you bus may have different timezone, your mobile phone may serve different timezone... and there can be a daylight saving on each of these timezone and it has different start and end for each one.
>
> It's pure insanity.
>
> https://english.news.cn/20220328/8a1ad2ddbde14941a6f208f1f175b550/c.html
>
> AW
>
> On Sunday, March 24th, 2024 at 04:32, Daniel Gutson <danielgutson@...il.com> wrote:
>
>> El sáb, 23 mar 2024, 23:04, Rich Felker <dalias@...c.org> escribió:
>>
>>> On Sat, Mar 23, 2024 at 08:40:50PM +0000, Alexander Weps wrote:
>>>> Yes, the behavior is the same here glibc and musl and it can't
>>>> reliably determine start of the day etc. Which is I assume expected.
>>>>
>>>> That's why there is tm_isdst = -1.
>>>>
>>>> I don't see any reliable way to determine beginning of the day without it.
>>>
>>> It's rather inherent to the horribleness of DST that determining the
>>> "beginning of the day" is not easy. In fact, it might not even be
>>> well-defined, depending on where your timezone puts its transition (it
>>> could happen right at midnight just to be evil; that it doesn't is
>>> only a matter of polite convention).
>>>
>>>> If I want to get beginning of the day I do it this way:
>>>>
>>>> before: 2010-10-31 14:00:00 CET
>>>> tm_sec: 0
>>>> tm_min: 0
>>>> tm_hour: 14
>>>> tm_mday: 31
>>>> tm_mon: 9
>>>> tm_year: 110
>>>> tm_wday: 0
>>>> tm_yday: 303
>>>> tm_isdst: 0
>>>> tm_gmtoff: 3600
>>>> tm_zone: CET
>>>>
>>>> tm.tm_isdst = -1; <-- setting tm_isdst = -1
>>>> tm.tm_hour = 0;
>>>> mktime(&tm);
>>>>
>>>> after: 2010-10-31 00:00:00 CEST
>>>> tm_sec: 0
>>>> tm_min: 0
>>>> tm_hour: 0
>>>> tm_mday: 31
>>>> tm_mon: 9
>>>> tm_year: 110
>>>> tm_wday: 0
>>>> tm_yday: 303
>>>> tm_isdst: 1
>>>> tm_gmtoff: 7200
>>>> tm_zone: CEST
>>>>
>>>> Is there a way, how to reliable get beginning of day etc. without
>>>> tm_isdst = -1.
>>>
>>> Depending on how you want to define it, yes, but it may need a second
>>> call to mktime. First, call mktime with 00:00:00 and tm_isdst=0. If
>>> the result has tm_isdst==0, you're done. If not, try again with the
>>> original struct tm input but tm_isdst changed to 1. The only way this
>>> procedure will fail is if the time 00:00:00 *does not exist* on that
>>> particular day.
>>
>> I was so curious about this that I asked Perplexity for an example:
>>
>> "For example, in the case of Samoa as mentioned in the search results, on December 30, 2011, the time went from 23:59:59 on December 29 straight to 00:00:00 on December 31, effectively skipping December 30 entirely as the country moved west of the International Date Line and also changed its time zone from UTC-11 to UTC+13"
>> (https://www.caktusgroup.com/blog/2019/03/21/coding-time-zones-and-daylight-saving-time/)
>>
>> This is sadly entertaining.
>>
>>> Note that if DST ends such that there are two times 00:00:00 on a
>>> particular day, this will pick the second (non-DST) one, as the first
>>> one might only be the new day temporarily, then jump back to the old
>>> day, which does not strike me as a good "beginning of the day". You
>>> could flip the order you try them around if you prefer to count it.
>>>
>>> Rich
Content of type "text/html" skipped
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.
