From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <musl-return-20720-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=-3.0 required=5.0 tests=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 200562158C
	for <ml@inbox.vuxu.org>; Sun, 24 Mar 2024 19:01:54 +0100 (CET)
Received: (qmail 15850 invoked by uid 550); 24 Mar 2024 17:57:11 -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 15812 invoked from network); 24 Mar 2024 17:57:10 -0000
Date: Sun, 24 Mar 2024 14:02:00 -0400
From: Rich Felker <dalias@libc.org>
To: Alexander Weps <exander77@pm.me>
Cc: musl@lists.openwall.com, Daniel Gutson <danielgutson@gmail.com>,
	Markus Wichmann <nullplan@gmx.net>
Message-ID: <20240324180200.GW4163@brightrain.aerifal.cx>
References: <k-ThelZ9H3lbpQTYR4-HcBxsI_dzqStE-6fmE2NXSegDpA8u_c1KoRMWBhBu0Q5phyH67pQtbJ1x6qTEwnwpcY_ln1G1vI85TFOqbqlk4zE=@pm.me>
 <20240324170436.GV4163@brightrain.aerifal.cx>
 <0_9-JV2MW3avVvzhE9vjqKqCX0fEZy0uUuZKIohFGEFDBY912nwZyxZe560H0cf_b8L2gD8e0eUAUp2Q3e1rmra3XEppx9HPhhFeulwLYZA=@pm.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0_9-JV2MW3avVvzhE9vjqKqCX0fEZy0uUuZKIohFGEFDBY912nwZyxZe560H0cf_b8L2gD8e0eUAUp2Q3e1rmra3XEppx9HPhhFeulwLYZA=@pm.me>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [musl] Broken mktime calculations when crossing DST boundary

On Sun, Mar 24, 2024 at 05:12:35PM +0000, Alexander Weps wrote:
> Adding seconds cannot make time go backwards. If that is how it was
> interpreted, than the interpretation is erroneous.

And subtracting seconds can't make time go forwards, but that's what
would happen with the alternate interpretation you want.

There is fundamentally no way for the interface to read your mind and
know that the time you requested is "move forward from a past valid
normalized time" and not "move backward from a future valid normalized
time".

Rich