[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFdMc-2DGdTJRnPYwyPP96T_830b2O29etqAK1gO_E7B=OMFPQ@mail.gmail.com>
Date: Sun, 24 Mar 2024 00:32:00 -0300
From: Daniel Gutson <danielgutson@...il.com>
To: musl@...ts.openwall.com
Cc: Alexander Weps <exander77@...me>, Markus Wichmann <nullplan@....net>
Subject: Re: Broken mktime calculations when crossing DST boundary
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.
