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=-2.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 605252291E for ; Sun, 24 Mar 2024 21:50:59 +0100 (CET) Received: (qmail 7173 invoked by uid 550); 24 Mar 2024 20:46:15 -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 6116 invoked from network); 24 Mar 2024 20:46:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1711313446; x=1711572646; bh=5+m/Xko4VnbNNshJSFWndmPzFztMi77U9ufp7drH7zA=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=c5H73DjWKKoZ1g5CYGKr0helx6JLaVuRHPEsV1gRMSlmM9EDqxx4wzGlWmEXOYWh9 8ojTf4DAp422hk32AEGQLpoEESdOgz68S2ZwyIFCAfYEGf7jQXAKT/pvqDOGHK2yfa Or1ivWMPQ1jDj2GbsK+MlMPUyvg8uOe2GX5HagUjdXrtu16JgH4KGvY8xqQ6Hk4UKL QonZbkjiQeIS01rQT5REhLrwRp9rtJZxUjLqCU/xp5Vm+ubUJh3vXk8ieEilNxU4lu fc5rE0Dakn12a/TmxzQ8mGC5D+7jDbFxk8+zr0nT39JK3MK0PGkGsfgir6XYFdLSl2 qTPDhuXnZYo+w== Date: Sun, 24 Mar 2024 20:50:41 +0000 To: musl@lists.openwall.com From: Alexander Weps Cc: Daniel Gutson , Markus Wichmann Message-ID: In-Reply-To: <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> <20240324202211.GZ4163@brightrain.aerifal.cx> Feedback-ID: 20507743:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Broken mktime calculations when crossing DST boundary See below. AW On Sunday, March 24th, 2024 at 21:22, Rich Felker wrote: > 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=3D70). 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=3D31 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. This is what is called limitations. I actually investigated this limitation very closely. And it doesn't influence ordering if you don't handle it at all. > > 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. No. The reasonable, consistent, least-surprising thing to do is to take a minim= al subset of assumptions to make viable ordering. So time can be predictably incremented and decremented and doesn't go backw= ards to run into loops like these: 1946-12-01 02:59:17 CET 1946-12-01 01:00:16 CET 1919-11-13 23:59:32 LMT 1919-11-13 23:54:01 LMT Reasonable is also to behave similarly as other implementations. > > > > You're making test cases which involve both 1 and 2 above, which make= s > > > 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. Then provide an example. > > > > 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. I am not sure if this is a serious conversation. I have a struct tm created by mktime. So this is a valid structure that was= produced by mktime. I increment a field (be it second, minute, hour...) in that structure. I call mktime to give me result of that calculation. Result of mktime is a s struct tm that has earlier time than the original s= truct tm. One of the primary purposes of struct tm and mktime is to make calculations= . Currently the implementation in musl cannot take a date represented in stru= ct tm and iteratively increment it in second intervals to generated all dat= es up to some date. This basically means, that some calculations are imposs= ible to make. It cannot reliably take a date and add seconds, minutes, hour= s, days... to that date and get the result. > > Rich