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_INVALID,DKIM_SIGNED, 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 6B30F21161 for ; Tue, 26 Mar 2024 00:00:16 +0100 (CET) Received: (qmail 11325 invoked by uid 550); 25 Mar 2024 22:55:29 -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 11290 invoked from network); 25 Mar 2024 22:55:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1711407603; x=1711666803; bh=TLWWIbTrpqiPA6A2vdT+GArkF0QrWxXjs6HUvUXKSWk=; h=Date:To:From:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=Par/Wi5e23QDlXKWajykYrMsc1qiedttxwmQ8zZDkDoQFOddLJ3qyDyFyE/Q/bEJU 5kZ0VAgc+A7TyrNzuqLaUuKyfWKwb5fwHXlXV65UPZBWB2WIOc0MGDmGzK9IVlRlFF uV9RX04A9rViC5sGpho8VhnxmNMP8oo+wbPCufUdhFmtXW5I1qxI0lZCfTmgOgA79U 1drUaAxzR/TF23eCaDVIp72RXB6gzdofdrTcrldgSX1jh7CggcUveaPAPx7gQBXZM1 LMg9sCjCrGiKiGB6FMFstAIiXD4NELppbip9rSK18J65qByzwEGwG9ns5ZPeYLLARC NWkLyeCeJaicQ== Date: Mon, 25 Mar 2024 22:59:57 +0000 To: musl@lists.openwall.com From: Alexander Weps Message-ID: In-Reply-To: References: <20240324192258.GY4163@brightrain.aerifal.cx> <-svm5EdX4OFN9hKzgS2FP6N1lgUGjT7edQONkAfCywgsRitwT6Vw22W3sUUGY_pnKGIXBKlujMZhPCDkJAMCYbBA5uF-IYgzhj8WB0wBE-A=@pm.me> <4YlR0YRqzZlDIOVv6SP8UDoop89n8u7BvQl_7eXNTvDZnogXMxG1z-TLGIBf-O4edUphddXGfADbk_d7Uzb37g5JoH7vOIvvNRMFDxPWZok=@pm.me> <20240325122113.GB4163@brightrain.aerifal.cx> Feedback-ID: 20507743:user:proton 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 See below. AW On Monday, March 25th, 2024 at 23:40, Thorsten Glaser wrote: > Alexander Weps dixit: > > > On Monday, March 25th, 2024 at 13:21, Rich Felker dalias@libc.org wrote= : > > > > > On Mon, Mar 25, 2024 at 11:52:00AM +0000, Alexander Weps wrote: > > > > > Musl cannot reliably increment date by a day. Incrementing struct t= m > > > > 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. I am not calculating any time between. I am using struct tm and mktime to calculated a date with specific offset f= rom initial date. When I add 1 to tm_sec it means I am calculating a date that is one second = after the initial date. And all of this works in glibc. Is the argument that glibc being able to do basic struct tm calculations is= an incorrect behavior? > > > > > 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. Specify those constraints. > > > 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 offs= et > =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 decreme= nting > > > This is entirely correct, again. You=E2=80=99re starting from > 2011-12-28 01:00:00, you=E2=80=99re getting it back. Show me a function implementation that produces same time next day under th= is behavior you assume to be correct. > > bye, > //mirabilos > -- > =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 > -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2