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 B454320137 for ; Mon, 25 Mar 2024 19:28:38 +0100 (CET) Received: (qmail 25705 invoked by uid 550); 25 Mar 2024 18:23:52 -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 25673 invoked from network); 25 Mar 2024 18:23:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1711391305; x=1711650505; bh=qzPWaZw7tW9+lnJtz2JFlO+tFiN9+idYf0V4qbyUmIk=; 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=FtxOCZeEBjy8ugLcRlJVKy8H8RWqMeWIPcV1xmI4wWDJXkjX240jVktUaEx0BZKEf th7s1Ue62jvMAaGooka1xUK6heJa4ZE8VHLqpso040pWy3Qr3zfFl9iBEb8yYuc0Pt dptjU/I4Z24+tAqZGWZX+yTckOga5AP/QOVSNAutM6L1zNDS+scVRkPsS1DtprNSmb 5Sl+5rrzziYBYnVpvPiF7b3mM76xRulKPEo7Lh1YDjLJ0MVq6Eqwjuz3SZoWtvSlbi wjkH3mZcpg44xfJA1FJLDeSbNWmgMu9k1Sp3pG7S5s7OsCN/PcX87gsFlSaQAashMv jqPRMIbzEF+Eg== Date: Mon, 25 Mar 2024 18:28:14 +0000 To: Rich Felker From: Alexander Weps Cc: musl@lists.openwall.com Message-ID: In-Reply-To: <20240325180208.GF4163@brightrain.aerifal.cx> References: <20240324192258.GY4163@brightrain.aerifal.cx> <4YlR0YRqzZlDIOVv6SP8UDoop89n8u7BvQl_7eXNTvDZnogXMxG1z-TLGIBf-O4edUphddXGfADbk_d7Uzb37g5JoH7vOIvvNRMFDxPWZok=@pm.me> <20240325122113.GB4163@brightrain.aerifal.cx> <20240325131318.GD4163@brightrain.aerifal.cx> <20240325134252.GE4163@brightrain.aerifal.cx> <20240325180208.GF4163@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 On Monday, March 25th, 2024 at 19:02, Rich Felker wrote: > On Mon, Mar 25, 2024 at 09:42:53AM -0400, Rich Felker wrote: > > > On Mon, Mar 25, 2024 at 01:24:57PM +0000, Alexander Weps wrote: > > > > > See below. > > > > > > AW > > > > > > On Monday, March 25th, 2024 at 14:13, Rich Felker dalias@libc.org wro= te: > > > > > > > On Mon, Mar 25, 2024 at 12:55:28PM +0000, Alexander Weps wrote: > > > > > > > > > > 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 cor= rect, > > > > > > 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 that case. It is off by day. > > > > > > > > > > Because December only had 30 days, 31s day after normalization is > > > > > January 1st. > > > > > > > > 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 ar= e > > > > 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 norm= alization. > > > December 31s is 30th day of month represented as tm_mday =3D 30. > > > > OK, I meant tm_mday=3D31-1. > > > Um, no, where did you get that idea? I just assumed you were right > because I always forget which tm_* are off-by-1, but tm_mday is > one-based not zero-based: > > int tm_mday; // day of the month -- [1, 31] > > (per the standard). So how did you end up getting the wrong thing? Are > you even running the code you say you are? > I have to sincerely ask if you are feeling ok? You seem not able to follow this conversation. What idea do you mean? Also you have the codes. You can like "I don't know" run them yourself? You question I run those codes without trying to run them yourself? Again?! What is going on? Maybe I reiterate some basic facts for you and that will put you back on tr= ack. This was an example from an article provided earlier in this thread (by som= ebody). We are in TZ=3DPacific/Apia. The 30th December was skipped in 2011. There was no December 30th. So, there were only 30 days in December. 30th day of the month December was December 31st. And run those examples yourself. I have no idea why I am being questioned i= f they generate the output when you can easily verify it yourself. > Rich