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 3DF6122158 for ; Mon, 25 Mar 2024 14:13:11 +0100 (CET) Received: (qmail 18039 invoked by uid 550); 25 Mar 2024 13:08:26 -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 18004 invoked from network); 25 Mar 2024 13:08:26 -0000 Date: Mon, 25 Mar 2024 09:13:18 -0400 From: Rich Felker To: Alexander Weps Cc: musl@lists.openwall.com Message-ID: <20240325131318.GD4163@brightrain.aerifal.cx> References: <20240324182458.GX4163@brightrain.aerifal.cx> <9c2qfe36CoPBfKjzn1lDDZ_hfyNJCZW6-6ZTZlQgHAPr2djicIMMweEqUoQoQsDWsBt4AAZBL8vZlcsVCL950rYhcPpMDvhzDWean3oVHbs=@pm.me> <20240324192258.GY4163@brightrain.aerifal.cx> <-svm5EdX4OFN9hKzgS2FP6N1lgUGjT7edQONkAfCywgsRitwT6Vw22W3sUUGY_pnKGIXBKlujMZhPCDkJAMCYbBA5uF-IYgzhj8WB0wBE-A=@pm.me> <4YlR0YRqzZlDIOVv6SP8UDoop89n8u7BvQl_7eXNTvDZnogXMxG1z-TLGIBf-O4edUphddXGfADbk_d7Uzb37g5JoH7vOIvvNRMFDxPWZok=@pm.me> <20240325122113.GB4163@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 Mon, Mar 25, 2024 at 12:55:28PM +0000, Alexander Weps wrote: > > If you take your test program and switch it to initialize with > > tm_mday=31, then do -=1 instead of +=1, you'll find that it gives > > 2011-12-29 01:00:00 -10 as well, only now it seems like the correct, > > expected thing to happen. Any change to "fix" the case you're > > complaining about would necessarily break this case. > > So (- day, +day): > > Musl: > 2011-12-31 01:00:00 +14 > 2011-12-29 01:00:00 -10 > 2011-12-29 01:00:00 -10 > > Glibc: > 2012-01-01 01:00:00 +14 > 2011-12-31 01:00:00 +14 > 2012-01-01 01:00:00 +14 > > Seems like musl doesn't even interpret the initial struct tm > correctly in that case. It is off by day. > > Because December only had 30 days, 31s day after normalization is > January 1st. This is nonsense. December has a day 31, which you can clearly see from the glibc output. For this particular year in this zone, with the zone rule change, there are "only 30 days" in December, but they are numbered 1-29 and 31, not 1-30. What did you do that got glibc to output 2012-01-01? I guess you wrote code to do some wacky arithmetic *after* the original code you already had, rather than *changing* the code to start with 2011-12-31 as I suggested to get a look at what's happening. > > In any case, the core issue you're hitting here is that time zones are > > HARD to work with and that there is inherent complexity that libc > > cannot save you from. You only got lucky that what you were trying to > > do "worked" with glibc because you were iterating days forward; if you > > were doing reverse, it would break exactly the same way. > > I am not really commenting on this, until you sort out the above > inconsistencies. I already have but you refuse to look. Rich