From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_FONT_FACE_BAD,HTML_MESSAGE, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 16498212CC for ; Sun, 24 Mar 2024 04:32:29 +0100 (CET) Received: (qmail 30704 invoked by uid 550); 24 Mar 2024 03:27:46 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 30659 invoked from network); 24 Mar 2024 03:27:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711251134; x=1711855934; darn=lists.openwall.com; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=BlVaRwhlme//MbvWDKt1zuBySn76ikCrTz/o4uzexHw=; b=UYi5QgNzFmdGusZzLtFoaWLjnGvdoUjtBA/RULxcdH9wfEtuld0jjsBGdHkJPG+RZJ SbbkLlhwxgC6TqfPUsoejEVhq22zd9XgKJj9jkZ760NIes4YXucMh1sD1dOA4SZkpLwZ r4zPmGrno6XZlZXW+hNMOOu9K1idijahDpqym/Lc1NPFCP81WJrmfL0qd/WNHIvZzNMY Y4x8JU6UJFm3Mpa5BV0fYQbMUy2ddnL1ceqFPB+Npmnpi2RwK6V1e9i303LA1rZeIdDo c/3bl/P+1roQs2VjMPIsBP/Lqoe1xOr7MjxoRsWJSBhEM+tGlUoT486+4jCNL6wEac8g 48CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711251134; x=1711855934; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=BlVaRwhlme//MbvWDKt1zuBySn76ikCrTz/o4uzexHw=; b=P+deIhYbo9s0e7Llo7vpCMMIwAo8nXsErOyxN1Vn/2pPJa/RLPPsqiq3Ftceavh9/u FqA/UZyKVocJ1o2Y9+QrVkyvO/EKVdVIs8GkSUYXE0JqubvCUuzgdhjzcZMCj59W9tPV WwJpUf1k7/Ke4b6W6ksxbkVetu6wOLOE7t+jZayUkQDC/z+hLYq4UhoeGJ6yKMMP/nNh p38d4WCCpiwF6k8cJzhRjdxsDJjZvz+WzKLi7rPXoPbvYj0nz6k8noEgmgiHU+a+VrF+ FQjs1vlgk01fLcuEqAnv6CO3RegcOd4CPfkKCmv6c6eCKml8i3zAbAY2in/VKzt45kzb O4ZQ== X-Gm-Message-State: AOJu0Yxizvs9broLbnNTTKJ3D6EImYjfQLb+BNl/BFA2vBw2x5nz5qrh i577hJxSdjwMsmSKoUCgz4NVYBrXBfkFJ7g7LF9aEbHBYgbGmjqT2Ihgssf+pZpYY/Dhp6rfq3Z wlzKXfDY6QvN8OSIJOTGhzCDntA+0jDiw X-Google-Smtp-Source: AGHT+IH98DESTjTHrDGrdEAephT3R6UrZTg4EvEdrhATSbkAf1OdNTYkfhyMq6O8RvYeM2W17n77EEX4+sRM818CTeU= X-Received: by 2002:a17:90a:b78f:b0:29c:7845:cba with SMTP id m15-20020a17090ab78f00b0029c78450cbamr3348784pjr.36.1711251133552; Sat, 23 Mar 2024 20:32:13 -0700 (PDT) MIME-Version: 1.0 References: <20240323123148.GR4163@brightrain.aerifal.cx> <5zS95V9QjlCRMv6JvbMFzFIOvxQTigAsEvu0YNSYzcu1ZHdki6sue6yqDXeWlRcSe_jhCQxHdHc0fvKu-3H7lCvyAeYgQTsK7KWMepbly3Y=@pm.me> <20240323153146.GS4163@brightrain.aerifal.cx> <-44SZR0LbVoyD5lp_9VrAFnIjGNbDvibCVUYEprqMToPidjopTHM4aLZuhjomrGJtvpGrc_gjrgK6roKWwunjEkk1y-BKRhtlGpWjnslQNA=@pm.me> <20240323201804.GT4163@brightrain.aerifal.cx> <6rPmS4jev9oFFibDdpKZ0mVRWLV3rhRcfqaUKu-5lPP7lc8zz8UH_kgPFA4r8wh1-qrYKfzVBpB0Ss6z4VMANASybmKZMeB9i3W3auYfhMI=@pm.me> <20240324020429.GU4163@brightrain.aerifal.cx> In-Reply-To: <20240324020429.GU4163@brightrain.aerifal.cx> From: Daniel Gutson Date: Sun, 24 Mar 2024 00:32:00 -0300 Message-ID: To: musl@lists.openwall.com Cc: Alexander Weps , Markus Wichmann Content-Type: multipart/alternative; boundary="000000000000efe4f006145fb384" Subject: Re: [musl] Broken mktime calculations when crossing DST boundary --000000000000efe4f006145fb384 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable El s=C3=A1b, 23 mar 2024, 23:04, Rich Felker escribi=C3= =B3: > 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 =3D -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 =3D -1; <-- setting tm_isdst =3D -1 > > tm.tm_hour =3D 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 =3D -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=3D0. If > the result has tm_isdst=3D=3D0, 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 > --000000000000efe4f006145fb384 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


El s=C3=A1b, 23 mar 2024, 23:04, Rich Felker <dalias@libc.org> escribi=C3=B3:
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 =3D -1.
>
> I don't see any reliable way to determine beginning of the day wit= hout 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 =3D -1; <-- setting tm_isdst =3D -1
> tm.tm_hour =3D 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 =3D -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=3D0. If
the result has tm_isdst=3D=3D0, 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 e= xample:

"For example, in the case of Samoa as mentioned in the search r= esults, on December 30, 2011, the time went from 23:59:59 on December 29 st= raight to 00:00:00 on December 31, effectively skipping December 30 entirel= y as the country moved west of the International Date Line and also changed= its time zone from UTC-11 to UTC+13"

=
This is sadly entertaining.= =C2=A0


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". Y= ou
could flip the order you try them around if you prefer to count it.

Rich
--000000000000efe4f006145fb384--