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=-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 507CC2022E for ; Sun, 24 Mar 2024 19:24:52 +0100 (CET) Received: (qmail 25617 invoked by uid 550); 24 Mar 2024 18:20:09 -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 24541 invoked from network); 24 Mar 2024 18:20:09 -0000 Date: Sun, 24 Mar 2024 14:24:59 -0400 From: Rich Felker To: Alexander Weps Cc: musl@lists.openwall.com, Daniel Gutson , Markus Wichmann Message-ID: <20240324182458.GX4163@brightrain.aerifal.cx> References: <20240324170436.GV4163@brightrain.aerifal.cx> <0_9-JV2MW3avVvzhE9vjqKqCX0fEZy0uUuZKIohFGEFDBY912nwZyxZe560H0cf_b8L2gD8e0eUAUp2Q3e1rmra3XEppx9HPhhFeulwLYZA=@pm.me> <20240324180200.GW4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 06:16:20PM +0000, Alexander Weps wrote: > > And subtracting seconds can't make time go forwards, but that's > > what would happen with the alternate interpretation you want. > > That's just nonsense. > > I can go from 1900 to 2200 by adding seconds. > And from 2200 to 1900 by subtracting seconds. > > I just did that using glibc. > > This is because each addition to struct tz fields leads to time > going forward and each subtraction from struct tz fields leads to > time going backwards.. As it should. > > There is clear ordering of struct tz contents. This is getting really tiring. In the presence of times which do not exist, the properties you want are not mathematically consistent. EITHER you get cases where "start from time T, add something, normalize" gives a broken-down time that looks like it's before T (but isn't, because it's in a different zone rule), OR you get cases where "start from time T, subtract something, normalize" gives a broken-down time that looks like it's after T (bit isn't, because it's in a different zone rule). Preferring one of these nasty behaviors over the other is entirely arbitrary. Time zones are nasty. Local time is nasty. If you want to do things with it, you have to deal with that nastiness. Rich