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 A87EC2139E for ; Mon, 25 Mar 2024 14:13:59 +0100 (CET) Received: (qmail 20331 invoked by uid 550); 25 Mar 2024 13:09:14 -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 20298 invoked from network); 25 Mar 2024 13:09:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1711372427; x=1711631627; bh=uvWR/mv0TZbWaIgVoku5y8p9VLKQcbuxzxQV/ev93IU=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=kh6x7GCBjpcGmOG2oFJ2PwbT27WgX0UVkjv93uUvBwM4yPKMLxHOTsnSWpu2mNqIb 6gef5N3POzTlXa3lHo5za5OjTBZuT1+AfCgzU8KAgFc1UYefV8LYIp704JSX1JmqrA XH/5RS7/9C6UaIe4pRWkmwEx+4rWXXUzwofqPEgKLKnBp3RBX8CUwQQgO30TkmkNg0 4GlTNwf1wklCJgtYEljWC8tex7lwRwqb4YhgS6XepOsfkH5/6DTkqe2UCozpqwXEAO XKbl7gvVjge4y4ULqZhq1EmfyVAMy+DmlkLxkR1rAxBxvZJfc2FUZu8hq48q2zQFRY l+eyUjQcqfTOQ== Date: Mon, 25 Mar 2024 13:13:20 +0000 To: Rich Felker From: Alexander Weps Cc: musl@lists.openwall.com Message-ID: In-Reply-To: <20240325130803.GC4163@brightrain.aerifal.cx> References: <20240324192258.GY4163@brightrain.aerifal.cx> <-svm5EdX4OFN9hKzgS2FP6N1lgUGjT7edQONkAfCywgsRitwT6Vw22W3sUUGY_pnKGIXBKlujMZhPCDkJAMCYbBA5uF-IYgzhj8WB0wBE-A=@pm.me> <4YlR0YRqzZlDIOVv6SP8UDoop89n8u7BvQl_7eXNTvDZnogXMxG1z-TLGIBf-O4edUphddXGfADbk_d7Uzb37g5JoH7vOIvvNRMFDxPWZok=@pm.me> <20240325122113.GB4163@brightrain.aerifal.cx> <20240325130803.GC4163@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 Have you read that e-mail? That case is addressed there as well... So I am putting it here again, so you don't need to search for it: > If you take your test program and switch it to initialize with > tm_mday=3D31, then do -=3D1 instead of +=3D1, you'll find that it gives > 2011-12-29 01:00:00 -10 as well, only now it seems like the correct, > expected thing to happen. Any change to "fix" the case you're > complaining about would necessarily break this case. So (-day, +day): Musl: 2011-12-31 01:00:00 +14 2011-12-29 01:00:00 -10 2011-12-29 01:00:00 -10 Glibc: 2012-01-01 01:00:00 +14 2011-12-31 01:00:00 +14 2012-01-01 01:00:00 +14 Seems like musl doesn't even interpret the initial struct tm correctly in t= hat case. It is off by day. Because December only had 30 days, 31s day after normalization is January 1= st. So no, musl is not correct, it is even more incorrect. Jesus Christ. AW On Monday, March 25th, 2024 at 14:07, Rich Felker wrote: > On Mon, Mar 25, 2024 at 12:55:28PM +0000, Alexander Weps wrote: > > > See below. > > > > AW > > > > 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: > > > > > > > This is the simplest and most obvious example how broken the > > > > calculation in musl is: > > > > > > > > void test10() > > > > { > > > > time_t t =3D 0; > > > > struct tm tm =3D {0}; > > > > char buf[64]; > > > > > > > > tm.tm_year =3D 2011 - 1900; > > > > tm.tm_mon =3D 12 - 1; > > > > tm.tm_mday =3D 29; > > > > tm.tm_hour =3D 0; > > > > tm.tm_min =3D 0; > > > > tm.tm_sec =3D 0; > > > > tm.tm_isdst =3D 0; > > > > > > > > strftime(buf, sizeof buf, "%F %T %Z", &tm); > > > > printf("before: %s %ld %ld\n", buf, t, calc(&tm)); > > > > > > > > t =3D mktime(&tm); > > > > > > > > strftime(buf, sizeof buf, "%F %T %Z", &tm); > > > > printf("after1: %s %ld %ld\n", buf, t, calc(&tm)); > > > > > > > > tm.tm_mday +=3D 1; > > > > t =3D mktime(&tm); > > > > > > > > strftime(buf, sizeof buf, "%F %T %Z", &tm); > > > > printf("after2: %s %ld %ld\n", buf, t, calc(&tm)); > > > > } > > > > > > > > TZ=3DPacific/Apia > > > > Year is greater than 1970. > > > > > > > > Input: > > > > 2011-12-29 01:00:00 -10 > > > > > > > > Add a day: > > > > tm.tm_mday +=3D 1; > > > > t =3D mktime(&tm); > > > > > > > > Output: > > > > 2011-12-29 01:00:00 -10 > > > > > > > > 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. > > > > > > > > Causing a program to loop or stack overflow. > > > > > > I thought you had found a real bug here, and spent some time working > > > out the math by hand on paper because local time is so headbangingly > > > awful and confusing. In the end, the conclusion I'm left with is that > > > it's working just as expected. > > > > It isn't. > > > > 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 > > > > tm.tm_mday -=3D 1; > > t =3D mktime(&tm); > > > Read my mail again. I'm talking about starting from 2011-12-31 and > decrementing. > > Rich