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 7F5C52203E for ; Mon, 25 Mar 2024 21:00:41 +0100 (CET) Received: (qmail 9521 invoked by uid 550); 25 Mar 2024 19:55:55 -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 9483 invoked from network); 25 Mar 2024 19:55:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1711396828; x=1711656028; bh=4jh57KQXAYK5R10BgprKr0ly3wNmEcOZS5R6Tz0V2FI=; 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=DH5RmvYJ/Egv12NpeLqt6wGX9oOY7VZdccTSWu0FE5wX3ANxyEHjHBU0SQa7RlPy+ P9lRbSMhE/ctGwRTbRevitdlj50EeOpGbxjBBu08rb1XhBRYxsQpGKY8I9qevCIHIo B8A8Km24gaW32HC82IS5WdPuhyXE0cr4BWqKW/s3vSI5VAKA9Xjy2CJfcsQC+j5o3j xCyIRUMXUqkT7bbNbfVkC9oF7hPs+jhhd5WJNdG6el1ntkt4JzIJn9wE260EtE44P6 j09C+mdXW457YDMlm9j1w/tybwm2U8i6fZ5UHAlvx0qFVfn/urORYkEcVRybrO3kE1 /DSmXiszD8g+w== Date: Mon, 25 Mar 2024 20:00:19 +0000 To: musl@lists.openwall.com From: Alexander Weps Message-ID: In-Reply-To: <20240325193813.GH4163@brightrain.aerifal.cx> References: <20240324192258.GY4163@brightrain.aerifal.cx> <20240325131318.GD4163@brightrain.aerifal.cx> <20240325134252.GE4163@brightrain.aerifal.cx> <20240325180208.GF4163@brightrain.aerifal.cx> <20240325185339.GG4163@brightrain.aerifal.cx> <4-8Ne4x6ZXfJmyaJ2YBFpLfCYySv9--JLQJl9OcSwaKyCashDhJXsqAPuh7G8QYwQpn2JnjUJxfZX8t9Fo101Mg_6rwb_MpmbRhFRUpYoz8=@pm.me> <20240325193813.GH4163@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 20:38, Rich Felker wrote: > On Mon, Mar 25, 2024 at 06:57:49PM +0000, Alexander Weps wrote: > > > I am not sure which one you mean, all latest codes even includes > > headers and main... > > > https://www.openwall.com/lists/musl/2024/03/25/3 > > > I have no idea what to tell you. > > > The first version I found that's actually compilable is: > > https://www.openwall.com/lists/musl/2024/03/25/11 > > It roughly behaves as expected on musl, except possibly not applying > the tm_isdst=3D0, which is what was making the output confusing on > glibc -- that threw the input back across the rule change cutoff. > > With tm_isdst=3D1 and tm_mday=3D31, on glibc, I get: > > before: 2011-12-31 00:00:00 WSDT 0 > after1: 2011-12-31 00:00:00 WSDT 1325239200 > after2: 2011-12-30 00:00:00 WSDT -1 > after3: 2011-12-31 00:00:00 WSDT 1325239200 > > The -1 in the after2 line indicates that mktime failed with an error > (and should not have modified tm; that's arguably a bug in glibc).The No, -1 means that was not able to make seconds since beginning of epoch. It has nothing to do with modifying tm... Also, can you share the whole code, you did some changes and I don't reprod= uce the result. Which sample it is based on? I set tm_isdst=3D1 and tm_mday=3D31 in the example above and I get: $ gcc foo.c -o foo && TZ=3DPacific/Apia ./foo before: 2011-12-31 00:00:00 +13 0 after1: 2012-01-01 01:00:00 +14 1325329200 after2: 2011-12-31 01:00:00 +14 1325242800 after3: 2012-01-01 01:00:00 +14 1325329200 I do not get any -1 results. $ musl-gcc foo.c -o foo && TZ=3DPacific/Apia ./foo before: 2011-12-31 00:00:00 0 after1: 2011-12-31 01:00:00 +14 1325242800 after2: 2011-12-29 01:00:00 -10 1325156400 after3: 2011-12-29 01:00:00 -10 1325156400 > partial modification that it made reflects the initial normalization > (type 1 in my notation) but not the rule change normalization (type 2 > in my notation) since glibc has failed the operation for an input date > that does not exist on the calendar (it does not do type 2 > normalization at all; it just rejects it). > > Running this same change on musl, I get: > > before: 2011-12-31 00:00:00 0 > after1: 2011-12-31 00:00:00 +14 1325239200 > after2: 2011-12-29 00:00:00 -10 1325152800 > after3: 2011-12-29 00:00:00 -10 1325152800 > > which again is what I expect. From one side, the move-by-1-day changes > the time to the next calendar day in that direction. From the other > side, it's unable to change it. Glibc works without any issues as shown above on my machine. Both forward a= nd backward. Your results are off by one hour. And you start with WSDT (+14). Without mk= time. The initial date produced by glibc should be +13 as Pacific/Apia is += 13. > > I'll look into why the tm_isdst=3D0 application was not happening. > > Rich > > > > > > > On Monday, March 25th, 2024 at 19:53, Rich Felker dalias@libc.org 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 w= rote: > > > > > > > > > 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 wr= ote: > > > > > > > > > > > > > > > > > > If you take your test program and switch it to initiali= ze with > > > > > > > > > > tm_mday=3D31, then do -=3D1 instead of +=3D1, you'll fi= nd 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 that case. It is off by day. > > > > > > > > > > > > > > > > > > Because December only had 30 days, 31s day after normaliz= ation is > > > > > > > > > January 1st. > > > > > > > > > > > > > > > > This is nonsense. December has a day 31, which you can clea= rly see > > > > > > > > from the glibc output. For this particular year in this zon= e, 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 af= ter 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 righ= t > > > > > 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 yours= elf? > > > > You question I run those codes without trying to run them yourself?= Again?! > > > > 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 ru= n > > > 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 i= t > > > > 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)