From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <musl-return-20725-ml=inbox.vuxu.org@lists.openwall.com>
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-6.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	NICE_REPLY_A,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 A588E229C3
	for <ml@inbox.vuxu.org>; Sun, 24 Mar 2024 20:01:41 +0100 (CET)
Received: (qmail 18341 invoked by uid 550); 24 Mar 2024 18:56:57 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 18309 invoked from network); 24 Mar 2024 18:56:56 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zhasha.com;
	s=wirbelwind; t=1711306883;
	bh=HCdG31VjuisiaxVuFfzB4QN8kIospjfJR5BVp+aVJWY=;
	h=Date:From:To:Subject:In-Reply-To:References;
	b=dVqzPd+rQ3G7yDet7mF6C2aQwvl0VtnY3m7oaw5f01+usDulhiaUGkOnigvl8rKHw
	 QxVJ3/XrWVj/lgDzt5pMApDHvmjOizFR+Dsk7ejx66Q59lTua052ZgJtQ7kAhY1NV4
	 iqKDj37hyqjSLInk68oCCH2gd/GAZ7K6Laa6CR5k=
Date: Sun, 24 Mar 2024 20:01:22 +0100
From: Joakim Sindholt <opensource@zhasha.com>
To: musl@lists.openwall.com
Message-Id: <20240324200122.8feda8341011587ec6cccf61@zhasha.com>
In-Reply-To: <9c2qfe36CoPBfKjzn1lDDZ_hfyNJCZW6-6ZTZlQgHAPr2djicIMMweEqUoQoQsDWsBt4AAZBL8vZlcsVCL950rYhcPpMDvhzDWean3oVHbs=@pm.me>
References: <k-ThelZ9H3lbpQTYR4-HcBxsI_dzqStE-6fmE2NXSegDpA8u_c1KoRMWBhBu0Q5phyH67pQtbJ1x6qTEwnwpcY_ln1G1vI85TFOqbqlk4zE=@pm.me>
	<20240324170436.GV4163@brightrain.aerifal.cx>
	<0_9-JV2MW3avVvzhE9vjqKqCX0fEZy0uUuZKIohFGEFDBY912nwZyxZe560H0cf_b8L2gD8e0eUAUp2Q3e1rmra3XEppx9HPhhFeulwLYZA=@pm.me>
	<20240324180200.GW4163@brightrain.aerifal.cx>
	<CCbb8O1-Z_AJj1Cg6G7NLCneYZ5rqwJahHwwaIA8T1TAkz-qt8m2t46_wY_dIVpyRAwyKi67KrBW9xk2swvTF17S3tai_SM2IvjBvv1DgMw=@pm.me>
	<20240324182458.GX4163@brightrain.aerifal.cx>
	<9c2qfe36CoPBfKjzn1lDDZ_hfyNJCZW6-6ZTZlQgHAPr2djicIMMweEqUoQoQsDWsBt4AAZBL8vZlcsVCL950rYhcPpMDvhzDWean3oVHbs=@pm.me>
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: Re: [musl] Broken mktime calculations when crossing DST boundary

On Sun, 24 Mar 2024 18:36:40 +0000, Alexander Weps <exander77@pm.me> wrote:
> But there cannot be a case where you have normalized time add
> something, normalize and create normalized time that is lower and vice
> versa.

I'm curious. How do you imagine mktime, which takes only 1 parameter and
has no memory, deduces that to get the presently invalid 02:00:00
timestamp it's looking at you added 1 second to a valid 01:59:59
timestamp rather than say, subtracting 1 hour from a valid 03:00:00
timestamp?