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 4D409222F4 for ; Mon, 25 Mar 2024 21:13:16 +0100 (CET) Received: (qmail 1313 invoked by uid 550); 25 Mar 2024 20:08:31 -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 1275 invoked from network); 25 Mar 2024 20:08:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1711397584; x=1711656784; bh=f+kauxTyVeBR+g9j6lvcZPobzycIXMP+tGhkn+8uD6M=; 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=UxyNN/VkJNJzy9XeP+9YY24WfiwhvuLiYXmGSTzNwq7deGH7pvzLq9RWrucBzXsmz unPQl+Sha3CQcB1xMUNTi7iA5RrS4eG9TTgl21K2CuNsHuL7L5ThzhsJmtRQvytP1C WtUXI/CcYoKZXgipJy4WKhIiyMx6xPhP/ygHl9tHv/X8KmfzOsxzSfEkt6Yscl4WN8 mTLE2G95i4SpMI+/Z9PnJXllNbMSELeR0uhAcYHbJ3sIkSNkstuhrjkMTQtEcftrju AsVh6ZQboRM858P5RfjOsjwVN+xYLl/n5KXSLO8rQgM/G80xyv4hSJeU64xj/W21iG SZR4F/xB6JmZQ== Date: Mon, 25 Mar 2024 20:12:48 +0000 To: musl@lists.openwall.com From: Alexander Weps Message-ID: In-Reply-To: References: <20240325122113.GB4163@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> <20240325194725.GI4163@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 Analyzing this and Glibc behavior is perfectly valid for that case: + day, + day, - day, - day $ gcc foo.c -o foo && TZ=3DPacific/Apia ./foo before: 2011-12-31 00:00:00 +14 0 after1: 2011-12-31 00:00:00 +14 1325239200 after1: 2011-12-30 00:00:00 +14 -1 after2: 2011-12-29 00:00:00 -10 1325152800 after2: 2011-12-30 00:00:00 -10 -1 after3: 2011-12-31 00:00:00 +14 1325239200 I can go forward and backward in time. $ musl-gcc foo.c -o foo && TZ=3DPacific/Apia ./foo before: 2011-12-31 00:00:00 0 after1: 2011-12-31 00:00:00 +14 1325239200 after1: 2011-12-29 00:00:00 -10 1325152800 after2: 2011-12-28 00:00:00 -10 1325066400 after2: 2011-12-29 00:00:00 -10 1325152800 after3: 2011-12-29 00:00:00 -10 1325152800 Musl is off by 2 days and ran into a cycle. AW On Monday, March 25th, 2024 at 21:05, Alexander Weps wrot= e: > Sorry my bad, that was isdst =3D 0; > > $ gcc foo.c -o foo && TZ=3DPacific/Apia ./foo > before: 2011-12-31 00:00:00 +14 0 > after1: 2011-12-31 00:00:00 +14 1325239200 > after2: 2011-12-30 00:00:00 +14 -1 > after3: 2011-12-31 00:00:00 +14 1325239200 > > $ musl-gcc foo.c -o foo && TZ=3DPacific/Apia ./foo > 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 > > I agree with isdst =3D 1; reuslts. > > AW > > > > > On Monday, March 25th, 2024 at 20:47, Rich Felker dalias@libc.org wrote: > > > On Mon, Mar 25, 2024 at 03:38:13PM -0400, 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. > > > > No, it's deeper than this. glibc is offsetting the input by an entire > > day when tm_isdst=3D0, and I don't know why. It looks like a bug in > > glibc. > > > > > 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). Th= e > > > 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 dat= e > > > 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 change= s > > > the time to the next calendar day in that direction. From the other > > > side, it's unable to change it. > > > > > > I'll look into why the tm_isdst=3D0 application was not happening. > > > > Hmm, I must have misread the output. It seems to be correct with > > tm_isdst=3D0 too: > > > > 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 > > > > (If it's 00:00:00 in standard time, it's 01:00:00 in DST, so the > > initial time seems to have been interpreted correctly.) > > > > I also went back and tested both with tm_isdst=3D-1, and both glibc and > > musl do the same thing as they do with tm_isdst=3D1 (which is correct). > > > > Rich