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 5EB132282F for ; Mon, 25 Mar 2024 19:58:16 +0100 (CET) Received: (qmail 30402 invoked by uid 550); 25 Mar 2024 18:53:30 -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 30367 invoked from network); 25 Mar 2024 18:53:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1711393083; x=1711652283; bh=Rbp++SQPmGjyVj/PXMlUPPaZjjRSPJ7sN4RT52ivkwk=; 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=QoCXQEx3pv5hDXtE9Q3mJNRSckNRPawPNIdYtTgcmjBRi/AcoPM9P5ziac3/N5WMe Z7SqU6Z1IAcIXuzlNeuN8mm9GtKl5o1NHk6w6em+xT1czp9odazOah2v3fhFZAX+9H uNwJ5LOe6Qfce3noTh2ncU/4Gyug7rsL89/B8gm915jn1oLUjdwxvFxSYLtCDgmskg hQR9H/J5AC6tctkIzqde7PzHvmBRFWCHY/CvyPnDVOKeywiq3b7wrrtcLpS8knqvtM 0SKpHBirZnC035M/UA/DYv0d14fMyAn+D0hqwkSixrIiN21IDHPCwec8a1ggMODkck zpjeZYrKFKVuQ== Date: Mon, 25 Mar 2024 18:57:49 +0000 To: Rich Felker From: Alexander Weps Cc: musl@lists.openwall.com Message-ID: <4-8Ne4x6ZXfJmyaJ2YBFpLfCYySv9--JLQJl9OcSwaKyCashDhJXsqAPuh7G8QYwQpn2JnjUJxfZX8t9Fo101Mg_6rwb_MpmbRhFRUpYoz8=@pm.me> In-Reply-To: <20240325185339.GG4163@brightrain.aerifal.cx> References: <20240324192258.GY4163@brightrain.aerifal.cx> <20240325122113.GB4163@brightrain.aerifal.cx> <20240325131318.GD4163@brightrain.aerifal.cx> <20240325134252.GE4163@brightrain.aerifal.cx> <20240325180208.GF4163@brightrain.aerifal.cx> <20240325185339.GG4163@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 I am not sure which one you mean, all latest codes even includes headers an= d main... I have no idea what to tell you. AW On Monday, March 25th, 2024 at 19:53, Rich Felker wrote: > On Mon, Mar 25, 2024 at 06:28:14PM +0000, Alexander Weps wrote: > > > On Monday, March 25th, 2024 at 19:02, Rich Felker dalias@libc.org 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= wrote: > > > > > > > > > > > On Mon, Mar 25, 2024 at 12:55:28PM +0000, Alexander Weps wrote: > > > > > > > > > > > > > > If you take your test program and switch it to initialize w= ith > > > > > > > > tm_mday=3D31, then do -=3D1 instead of +=3D1, you'll find t= hat 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 that case. It is off by day. > > > > > > > > > > > > > > Because December only had 30 days, 31s day after normalizatio= n 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, w= ith the > > > > > > zone rule change, there are "only 30 days" in December, but the= y 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 = normalization. > > > > > 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? Ar= e > > > 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? Aga= in?! > > What is going on? > > > The first few pieces of code you posted did not work because they > depended on other code you did not include, so I stopped trying to run > them. > > > Maybe I reiterate some basic facts for you and that will put you > > back on track. > > > > This was an example from an article provided earlier in this thread (by= somebody). > > 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 if they generate the output when you can easily verify it > > yourself. > > > Which piece of self-contained, actually-runnable code would you like > me to look at that demonstrates something wrong? (i.e. not something I > have already said is behaving as expected) > > Rich