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 BA3AF20E5F for ; Mon, 25 Mar 2024 21:06:23 +0100 (CET) Received: (qmail 19687 invoked by uid 550); 25 Mar 2024 20:01:37 -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 19649 invoked from network); 25 Mar 2024 20:01:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1711397170; x=1711656370; bh=aE4UktXX/6+kqg4GZUk4HxMQS6BId1W8l+5VvvcBenw=; 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=m1o0INKkyEwK0j+LnmFGgcTjYoN+O385papetGmlecxuz7frdBP7p8+PEmZy7L8RM ke1ArhTQb3pScVeL92we0t/Y2faL54sRt9SN+EgsOVu3YyKd7NqQPBzDs/lqafYHNZ IkA0ctQYmWQ1gvggKEraqhwfqDoquxKJGy0h6M7v6oN7fcIR3m9tVhrNzeKmooXmSl 38LOVk5gsBme3wqyP3wRCbD2ctGhXWxyREPB87hgOqijqYTCX4I7m1+JX058gYAywR 0YonATqb4u+hkl71Gm5zCFxdesWy/T2M/+Tibs9odGkMUEIJ8H5yklFt0/BYBNaw5u 4MJxgel8/cx0Q== Date: Mon, 25 Mar 2024 20:05:50 +0000 To: musl@lists.openwall.com From: Alexander Weps Message-ID: In-Reply-To: <20240325194725.GI4163@brightrain.aerifal.cx> 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 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 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). The > > 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. > > > > 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