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=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, 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 AA265205E1 for ; Mon, 25 Mar 2024 23:40:34 +0100 (CET) Received: (qmail 3180 invoked by uid 550); 25 Mar 2024 22:35:47 -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 3136 invoked from network); 25 Mar 2024 22:35:47 -0000 Date: Mon, 25 Mar 2024 22:40:01 +0000 (UTC) From: Thorsten Glaser X-X-Sender: tg@herc.mirbsd.org To: musl@lists.openwall.com In-Reply-To: Message-ID: References: <20240324182458.GX4163@brightrain.aerifal.cx> <9c2qfe36CoPBfKjzn1lDDZ_hfyNJCZW6-6ZTZlQgHAPr2djicIMMweEqUoQoQsDWsBt4AAZBL8vZlcsVCL950rYhcPpMDvhzDWean3oVHbs=@pm.me> <20240324192258.GY4163@brightrain.aerifal.cx> <-svm5EdX4OFN9hKzgS2FP6N1lgUGjT7edQONkAfCywgsRitwT6Vw22W3sUUGY_pnKGIXBKlujMZhPCDkJAMCYbBA5uF-IYgzhj8WB0wBE-A=@pm.me> <4YlR0YRqzZlDIOVv6SP8UDoop89n8u7BvQl_7eXNTvDZnogXMxG1z-TLGIBf-O4edUphddXGfADbk_d7Uzb37g5JoH7vOIvvNRMFDxPWZok=@pm.me> <20240325122113.GB4163@brightrain.aerifal.cx> Content-Language: de-Zsym-DE-1901-u-em-text-rg-denw-tz-utc, en-Zsym-GB-u-cu-eur-em-text-fw-mon-hc-h23-ms-metric-mu-celsius-rg-denw-tz-utc-va-posix MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Subject: Re: [musl] Broken mktime calculations when crossing DST boundary Alexander Weps dixit: >On Monday, March 25th, 2024 at 13:21, Rich Felker wrote: >> On Mon, Mar 25, 2024 at 11:52:00AM +0000, Alexander Weps wrote: >> > Musl cannot reliably increment date by a day. Incrementing struct tm >> > representing 2011-12-29 01:00:00 -10 by one day leads to the same >> > date. No, that=E2=80=99s correct. Your chosen timezone has a discontinuity: $ TZ=3DPacific/Apia date -d @1325239199 Thu Dec 29 23:59:59 -10 2011 $ TZ=3DPacific/Apia date -d @1325239200 Sat Dec 31 00:00:00 +14 2011 This means any time between this simply does not exist in broken-down time. >> > Causing a program to loop or stack overflow. That=E2=80=99s because your application violates the constraints that bind both, not just the libc, to the spec. >Output from musl: > >2011-12-29 01:00:00 -10 > > tm.tm_mday +=3D 1; > t =3D mktime(&tm); > >2011-12-29 01:00:00 -10 <-- date is the same after incrementing This is=E2=80=A6 not as incorrect as you state. The steps here are: =E2=80=A2 2011-12-30 01:00:00 =E2=86=90 input =E2=80=A2 2011-12-30 01:00:00 =E2=86=90 input after normalisation (!) =E2=80=A2 conversion to time_t (1325206800), application of timezone offset =E2=80=A2 detection of the discontinuity between 2011-12-29 23:59:59 and 2011-12-31 00:00:00 =E2=80=A2 arbitrary choice of selecting either endpoint tbh I=E2=80=99d expect this to end up in 1325239199=3D2011-12-29 23:59:59 instead of 2011-12-29 01:00:00 though, at least from reading the latest Issue 8 proofreading draft. WDYT dalias? > tm.tm_mday -=3D 1; > t =3D mktime(&tm); > >2011-12-28 01:00:00 -10 <-- going below the original date while decrementi= ng This is entirely correct, again. You=E2=80=99re starting from 2011-12-28 01:00:00, you=E2=80=99re getting it back. bye, //mirabilos --=20 =E2=80=9CIt is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.=E2=80=9D =09-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2