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 29EC121786 for ; Mon, 25 Mar 2024 00:54:07 +0100 (CET) Received: (qmail 1640 invoked by uid 550); 24 Mar 2024 23:49:23 -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 1605 invoked from network); 24 Mar 2024 23:49:22 -0000 Date: Sun, 24 Mar 2024 23:51:26 +0000 (UTC) From: Thorsten Glaser X-X-Sender: tg@herc.mirbsd.org To: musl@lists.openwall.com In-Reply-To: <-svm5EdX4OFN9hKzgS2FP6N1lgUGjT7edQONkAfCywgsRitwT6Vw22W3sUUGY_pnKGIXBKlujMZhPCDkJAMCYbBA5uF-IYgzhj8WB0wBE-A=@pm.me> Message-ID: 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> Content-Language: de-Zsym-DE-1901-u-em-text-rg-denw-tz-utc, en-Zsym-GB-u-cu-eur-em-text-fw-mon-hc-h23-ms-metric-mu-celsius-rg-denw-tz-utc-va-posix 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 Alexander Weps dixit: >You are describing the musl behavior, more specifically what I see in mkti= me & __tm_to_secs. >I don't think this is correct behavior. This is what POSIX (Issue 8) and AFAIR also the next ISO C standard mandate, though: 1.=E2=80=936.=09struct tm is normalised from seconds or minutes up to year 7.=09struct tm is converted to time_t (wrongly written down as =09=E2=80=9Cthe number of seconds since the epoch=E2=80=9D as it omits leap =09seconds) 8.=09timezone corrections for standard time at the moment in =09time calculated in step 7 is applied 9.=09if the timezone has DST: =09+ if tm_isdst is positive, the time is adjusted by the offset =09+ if tm_isdst is negative, the result is either the same as =09 if it were 0 or the same as if it were 1; if the struct tm =09 specifies a gap or repeated segment, which of the two is =09 used is explicitly unspecified, i.e. the caller cannot rely =09 on the libc to guess his intent if he sets tm_isdst to -1. 10. (not numbered) for gaps or repeats, mktime uses either the value =09from before the gap/repeat or the one after, choice again =09unspecified Tough luck there. The wording in this part is interesting though: | If tm_isdst is positive, mktime() shall further adjust the seconds | since the Epoch by the DST offset. But I guess that if you call with tm_isdst=3D1 and a broken-down time that clearly corresponds to n=C5=8Dn-DST, the DST offset for it is just 0 and it=E2=80=99ll work out the obvious way. bye, //mirabilos --=20 =E2=80=9CIt is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.=E2=80=9D =09-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2