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 D13E622312 for ; Sun, 24 Mar 2024 18:12:57 +0100 (CET) Received: (qmail 18373 invoked by uid 550); 24 Mar 2024 17:08:14 -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 18341 invoked from network); 24 Mar 2024 17:08:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1711300364; x=1711559564; bh=Tt10mj2UFMSpilZm+z2jIoVojw9QbF2vgIfiUxBzJKo=; 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=S1qiM34LAUFIeuSClD323g1nqk9wILXdb9E8Yu90YoQgazpA0yiTW6iXKAqpw6DFM FQxtdgXG6k4Rjb59UM3WCFS07REeZGD1Sf2IWjBGVXDgy86Xhy+gbvLVFRv0urCDO/ ae+kg1CojXOJQK034L4pM5bKQHCW3e8GDook91GMCBM5iBcC9dRZ8+nOkNvV9Xvh3q xK5QedK7Sa5/mFDA61EmbK3I2uEgixoIDLPFCogLnGJzb66YN9knYVfRdDNOAl62uv u26kyEw9eowv79lrhum7gZv1Xwnce+jlDIgsLDtZko3sBcxYu6WBRVXp0FWktIqcpg nEJIBP52jAWfA== Date: Sun, 24 Mar 2024 17:12:35 +0000 To: musl@lists.openwall.com From: Alexander Weps Cc: Daniel Gutson , Markus Wichmann Message-ID: <0_9-JV2MW3avVvzhE9vjqKqCX0fEZy0uUuZKIohFGEFDBY912nwZyxZe560H0cf_b8L2gD8e0eUAUp2Q3e1rmra3XEppx9HPhhFeulwLYZA=@pm.me> In-Reply-To: <20240324170436.GV4163@brightrain.aerifal.cx> References: <20240324170436.GV4163@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 Adding seconds cannot make time go backwards. If that is how it was interpr= eted, than the interpretation is erroneous. I think I will do some test. If you start with 1900-01-01 00:00:00 and start adding seconds and calling = mktime, you should reliable get to 2200-12-31 59:59:59 in all timezones. Sa= me goes for minutes, hours, days, years. If that's not the case then the interpretation in musl is wrong. This is a basic elementary functionality of mktime. There can't be any going back in time a cycles. AW On Sunday, March 24th, 2024 at 18:04, Rich Felker wrote: > On Sun, Mar 24, 2024 at 01:36:42PM +0000, Alexander Weps wrote: > > > Also thanks for the Pacific/Apia example. Not only that it fails for th= at date: > > Pattern: * * * * * * > > Initial: 2011-12-29_23:59:59 > > Expected: 2011-32-31_00:00:00 > > Actual: 2011-12-29_00:00:00 > > My cron tool again going back in time. > > > > It fails one other test. > > > > I have to run my tests on multiple timezones. > > > > And it works in glibc. > > > > And that's after I removed tm_isdst and rewrote half the code to accomm= odate. > > > > Can We agree on some simple premise that with no uncertain STD/DST > > settings (tm_isdst =3D 0 or tm_isdst =3D 1), incrementing seconds by 1 > > and calling mktime should never cause time to go back? > > > > Well, behold Pacific/Apia: > > > > I set 2011-12-29 23:59:59: > > > > tm_sec: 59 > > tm_min: 59 > > tm_hour: 23 > > tm_mday: 29 > > tm_mon: 11 > > tm_year: 111 > > tm_wday: 0 > > tm_yday: 0 > > tm_isdst: 1 > > tm_gmtoff: 0 > > tm_zone: (null) > > > > Calling mktime to see if everything is correct: > > mktime(&tm); > > > > before: 2011-12-29 23:59:59 -10 > > tm_sec: 59 > > tm_min: 59 > > tm_hour: 23 > > tm_mday: 29 > > tm_mon: 11 > > tm_year: 111 > > tm_wday: 4 > > tm_yday: 362 > > tm_isdst: 1 > > tm_gmtoff: -36000 > > tm_zone: -10 > > > > Incrementing seconds and calling mktime: > > tm.tm_sec +=3D 1; > > mktime(&tm); > > > > after: 2011-12-29 00:00:00 -10 > > tm_sec: 0 > > tm_min: 0 > > tm_hour: 0 > > tm_mday: 29 > > tm_mon: 11 > > tm_year: 111 > > tm_wday: 4 > > tm_yday: 362 > > tm_isdst: 1 > > tm_gmtoff: -36000 > > tm_zone: -10 > > We went from: > > 2011-12-29 23:59:59 -10 > > To: > > 2011-12-29 00:00:00 -10 > > > > By adding 1 second. The tm_isdst was not set to -1. > > > > This is totally unreliable. > > > From what I understand, you've set the input to a time that doesn't > exist in the local timezone: 2011-12-30 00:00:00. This could be either > 1 second after 2011-12-29 23:59:59, as you intended, or 1 day before > 2011-12-31 00:00:00. The latter is how it was interpreted. However, it > does not seem to have correctly set tm_gmtoff to reflect how it was > interpreted. We should check this out because that's probably an > actual bug. > > Rich