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 636A9220D9 for ; Tue, 26 Mar 2024 00:36:00 +0100 (CET) Received: (qmail 21844 invoked by uid 550); 25 Mar 2024 23:31: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 21809 invoked from network); 25 Mar 2024 23:31:14 -0000 Date: Mon, 25 Mar 2024 23:34:43 +0000 (UTC) From: Thorsten Glaser X-X-Sender: tg@herc.mirbsd.org To: musl@lists.openwall.com In-Reply-To: Message-ID: References: <20240324192258.GY4163@brightrain.aerifal.cx> <-svm5EdX4OFN9hKzgS2FP6N1lgUGjT7edQONkAfCywgsRitwT6Vw22W3sUUGY_pnKGIXBKlujMZhPCDkJAMCYbBA5uF-IYgzhj8WB0wBE-A=@pm.me> <4YlR0YRqzZlDIOVv6SP8UDoop89n8u7BvQl_7eXNTvDZnogXMxG1z-TLGIBf-O4edUphddXGfADbk_d7Uzb37g5JoH7vOIvvNRMFDxPWZok=@pm.me> <20240325122113.GB4163@brightrain.aerifal.cx> 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: >And all of this works in glibc. Not at all, glibc=E2=80=99s mktime just throws the towel with EOVERFLOW saying that the requested time does not exist. (It is only not permitted to change the input struct tm member tm_wday if it returns EOVERFLOW but that doesn=E2=80=99t mean that the output struct tm is correct.) >> That=E2=80=99s because your application violates the constraints >> that bind both, not just the libc, to the spec. > >Specify those constraints. My wording here was badly, as dalias mentioned: >It's not a constraint violation. mktime is required to accept inputs >where the fields of the broken-down time don't fall within their >respective ranges, and normalize them. > >Rather, the calling code is just making incorrect assumptions about >the unspecified way that happens, [=E2=80=A6] The =E2=80=9Cconstraint=E2=80=9D (wrong word) I meant was that your program must not make assumptions about which of the two possible conflict resolutions the libc chooses. >Show me a function implementation that produces same time next day >under this behavior you assume to be correct. It is not possible to do that with mktime. You=E2=80=99ll have to do that yourself. POSIX even says so. It does indicate that on implementations (their word for libcs here) that follow its recommendation to not normalise tm_sec, you can achieve the desired effect by adding 86400 to it, though that will not work right in the presence of a leap second on systems honouring them (which is a deviation from POSIX, of course). Adding 86400 to the time_t value, under the same leap second caveat, can work if your code can rely on POSIX (ISO C does not specify the internal structure of time_t). bye, //mirabilos --=20 22:20=E2=8E=9C The crazy that persists in his craziness becomes a m= aster 22:21=E2=8E=9C And the distance between the craziness and geniality= is only measured by the success 18:35=E2=8E=9C "Psychotics are consist= ently inconsistent. The essence of sanity is to be inconsistently inconsistent