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 B2A2022323 for ; Sun, 24 Mar 2024 20:22:52 +0100 (CET) Received: (qmail 28559 invoked by uid 550); 24 Mar 2024 19:18: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 28524 invoked from network); 24 Mar 2024 19:18:08 -0000 Date: Sun, 24 Mar 2024 15:22:58 -0400 From: Rich Felker To: Alexander Weps Cc: musl@lists.openwall.com, Daniel Gutson , Markus Wichmann Message-ID: <20240324192258.GY4163@brightrain.aerifal.cx> References: <20240324170436.GV4163@brightrain.aerifal.cx> <0_9-JV2MW3avVvzhE9vjqKqCX0fEZy0uUuZKIohFGEFDBY912nwZyxZe560H0cf_b8L2gD8e0eUAUp2Q3e1rmra3XEppx9HPhhFeulwLYZA=@pm.me> <20240324180200.GW4163@brightrain.aerifal.cx> <20240324182458.GX4163@brightrain.aerifal.cx> <9c2qfe36CoPBfKjzn1lDDZ_hfyNJCZW6-6ZTZlQgHAPr2djicIMMweEqUoQoQsDWsBt4AAZBL8vZlcsVCL950rYhcPpMDvhzDWean3oVHbs=@pm.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9c2qfe36CoPBfKjzn1lDDZ_hfyNJCZW6-6ZTZlQgHAPr2djicIMMweEqUoQoQsDWsBt4AAZBL8vZlcsVCL950rYhcPpMDvhzDWean3oVHbs=@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 06:36:40PM +0000, Alexander Weps wrote: > It is tiring, because you are not correct. > > You are also talking about a slightly different thing. > > If you have normalized time T1 in struct tm and you add something, > normalize, you should always get normalized time T2, what is higher > than T1. > If you have normalized time T2 in struct tm and you subtract > something, normalize, you should always get normalized time T1, > which is lower than T2. > > I agree than for non normalized time (tm_isdst = -1 etc.) this would > not apply. I agree that the decision how to deduce it is > implementation specific and I don't really hold it against musl. I > rewrote everything without tm_isdst = -1. You're mixing up what non-normalized means. There are basically two meanings, neither of which has to do with tm_isdst=-1 (forget it because it's not relevant to any of this). 1. The value of one of the tm_* values it outside of its calendar range (e.g. tm_min=70). These are reduced prior to any consideration of timezone mess, producing a nominally valid calendar date. 2. The normalized (in sense 1 above) time in the tm_* values does not exist due to daylight time change (spring-forward) or change in the timezone rule for the territory. You're making test cases which involve both 1 and 2 above, which makes them more confusing to reason about. > But there cannot be a case where you have normalized time add > something, normalize and create normalized time that is lower and > vice versa. > > If you claim otherwise, provide counter example. What I've told you is that, if you compare the broken-down tm element by element ignoring what zone rule it's under, there will always be instances where mktime is non order preserving, *regardless of what choices the implementation makes*. One way of writing this precisely is that there will always exist tm1 and tm2 where timegm(tm1) < timegm(tm2) but after mktime(tm1) and mktime(tm2): timegm(tm1) > timegm(tm2) This is really not profound. It's just a case of "local times are lossy in the absence of also taking into account the associated UTC offset or local time rule in effect". I think you've found one real bug where something goes wrong with the 2011-12-29 corner case, but digging in on other things you think are wrong, that are just fundamental to how local time works, is distracting from actually investigating that. Can we try to actually figure out what's going on there? Rich