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 EB0ED226A3 for ; Mon, 25 Mar 2024 14:25:53 +0100 (CET) Received: (qmail 1713 invoked by uid 550); 25 Mar 2024 13:21:08 -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 1678 invoked from network); 25 Mar 2024 13:21:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1711373140; x=1711632340; bh=wIu+sul2OdJeRZGo8f9mTKZQf0kCf9VGsDCKURcfW2g=; 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=nF9d0PVC2zWVJU3QqmsSvxYit0OU1SNqsdbsGKMy/v8uXtF5Yjuy1B1dLOdlqi8Br 37EUlF2rpEmNjAl/qBRUwGyxZihRK6tpZfzNtGYF5JQAhKiDHAg0SOWzVzIzWzmDdd PyjzcattquoWkZH2t+Mc2sMP4ErJGhfesdOgnfeQNDShS6qgdl3Ea9XYRw80BQV+Ph 0VgD5x3N0W/VLZGBOfntRVHWxQBW0uFG3oYl51Q/EBwOaOqZuxXbDOYLMbR27v1aqr dgvxG/qqWXHoDPIRwCXgQjsKsfh2yW9mvpy/TsVFWwTONDBn2hwP3RfvcN6Bhyf/9z RgCB5avV1OwiA== Date: Mon, 25 Mar 2024 13:24:57 +0000 To: Rich Felker From: Alexander Weps Cc: musl@lists.openwall.com Message-ID: In-Reply-To: <20240325131318.GD4163@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> <20240325131318.GD4163@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 14:13, Rich Felker wrote: > On Mon, Mar 25, 2024 at 12:55:28PM +0000, Alexander Weps wrote: >=20 > > > 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 giv= es > > > 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. > >=20 > > So (- day, +day): > >=20 > > Musl: > > 2011-12-31 01:00:00 +14 > > 2011-12-29 01:00:00 -10 > > 2011-12-29 01:00:00 -10 > >=20 > > Glibc: > > 2012-01-01 01:00:00 +14 > > 2011-12-31 01:00:00 +14 > > 2012-01-01 01:00:00 +14 > >=20 > > Seems like musl doesn't even interpret the initial struct tm > > correctly in that case. It is off by day. > >=20 > > Because December only had 30 days, 31s day after normalization is > > January 1st. >=20 >=20 > This is nonsense. December has a day 31, which you can clearly see > from the glibc output. For this particular year in this zone, with the > zone rule change, there are "only 30 days" in December, but they are > numbered 1-29 and 31, not 1-30. You confuse day of month which is represented in tm_mday with calendar day = that is interpreted by strftime. You said to set tm_mday =3D 31, which would be January 1st after normalizat= ion. December 31s is 30th day of month represented as tm_mday =3D 30. >=20 > What did you do that got glibc to output 2012-01-01? I guess you wrote > code to do some wacky arithmetic after the original code you already > had, rather than changing the code to start with 2011-12-31 as I > suggested to get a look at what's happening. >=20 > > > In any case, the core issue you're hitting here is that time zones ar= e > > > HARD to work with and that there is inherent complexity that libc > > > cannot save you from. You only got lucky that what you were trying to > > > do "worked" with glibc because you were iterating days forward; if yo= u > > > were doing reverse, it would break exactly the same way. > >=20 > > I am not really commenting on this, until you sort out the above > > inconsistencies. >=20 >=20 > I already have but you refuse to look. It was addressed, do didn't scroll at the end of the e-mail. >=20 > Rich