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 501C421632 for ; Sun, 24 Mar 2024 21:22:06 +0100 (CET) Received: (qmail 26528 invoked by uid 550); 24 Mar 2024 20:17:22 -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 26490 invoked from network); 24 Mar 2024 20:17:22 -0000 Date: Sun, 24 Mar 2024 16:22:12 -0400 From: Rich Felker To: Alexander Weps Cc: musl@lists.openwall.com, Daniel Gutson , Markus Wichmann Message-ID: <20240324202211.GZ4163@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> <20240324192258.GY4163@brightrain.aerifal.cx> <-svm5EdX4OFN9hKzgS2FP6N1lgUGjT7edQONkAfCywgsRitwT6Vw22W3sUUGY_pnKGIXBKlujMZhPCDkJAMCYbBA5uF-IYgzhj8WB0wBE-A=@pm.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <-svm5EdX4OFN9hKzgS2FP6N1lgUGjT7edQONkAfCywgsRitwT6Vw22W3sUUGY_pnKGIXBKlujMZhPCDkJAMCYbBA5uF-IYgzhj8WB0wBE-A=@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 07:57:39PM +0000, Alexander Weps wrote: > > 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. > > You are describing the musl behavior, more specifically what I see > in mktime & __tm_to_secs. > I don't think this is correct behavior. > You basically throw away important information and later claim that > you don't have it and it's impossible to deduce it. This "important information" does not tell us what the caller did to get the non-normalized input we received, *even if you assume the caller just made a single change*. For example if you see tm_mday=31 in a month with only 30 days, you don't know if the caller was trying to move one day forward from the last day of the month, or was trying to move one month back from the next month. The reasonable, consistent, least-surprise thing to do is not to try to make guesses based on the individual fields and how you think the caller might have gotten to them, but instead to normalize completely to the ranges before even considering timezone shenanigans. > > 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 > > You made it non order preserving by your choices. You have just > shown that the implementation is broken by choices that were made. > You can make valid ordering of all struct tm if you consider all of > the fields. > > This is not even relevant to normalization. You can do it on all > struct tm just as they are. > Normalization should be there to make it easier to do it, not make > it impossible to do it. No, this happens regardless of the above. > > 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? > > Sure. But that's not the only bug. Well I haven't seen any other credible claims of a bug in this thread. Rich