I see other weird things in Pacific/Apia, but these are at least consistent with glibc (and not an utter nonsense like going back in time): tm_sec: 0 tm_min: 0 tm_hour: 1 tm_mday: 26 tm_mon: 8 tm_year: 110 tm_wday: 0 tm_yday: 0 tm_isdst: 1 tm_gmtoff: 0 tm_zone: (null) mktime(&tm); before: 2010-09-26 01:00:00 -10 tm_sec: 0 tm_min: 0 tm_hour: 1 tm_mday: 26 tm_mon: 8 tm_year: 110 tm_wday: 0 tm_yday: 268 tm_isdst: 1 tm_gmtoff: -36000 tm_zone: -10 tm.tm_hour = 0; mktime(&tm); after: 2010-09-25 23:00:00 -11 tm_sec: 0 tm_min: 0 tm_hour: 23 tm_mday: 25 tm_mon: 8 tm_year: 110 tm_wday: 6 tm_yday: 267 tm_isdst: 0 tm_gmtoff: -39600 tm_zone: -11 But here even doubly calling: tm.tm_hour = 0; mktime(&tm); tm.tm_hour = 0; mktime(&tm); Doesn't fix the issue, as you get: 2010-09-25 00:00:00 -11 There should be a reliable way how to determine a beginning of a day without tm_isdst = -1. I used that before. I can use that in glibc, but what can I do in musl? AW On Sunday, March 24th, 2024 at 14:36, Alexander Weps wrote: > 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 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 wrote: >> >>> El sáb, 23 mar 2024, 23:04, Rich Felker 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