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.1 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE 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 6472E2021B for ; Sat, 23 Mar 2024 13:31:42 +0100 (CET) Received: (qmail 24574 invoked by uid 550); 23 Mar 2024 12:27:02 -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 24534 invoked from network); 23 Mar 2024 12:27:02 -0000 Date: Sat, 23 Mar 2024 08:31:48 -0400 From: Rich Felker To: Alexander Weps Cc: Markus Wichmann , musl@lists.openwall.com Message-ID: <20240323123148.GR4163@brightrain.aerifal.cx> References: <528SeRFaPfDw7fA4kqKDlio1U4RB_t9nmUemPcWw9_t1e2hBDpXYFmOqxAC37szgYvAVtmTuXWsmT64SSN3cSQFVdrQqXUAgkdTMPZQ0bg0=@pm.me> 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 Sat, Mar 23, 2024 at 12:00:52PM +0000, Alexander Weps wrote: > This is how it should work as far as I am concerned. After > manipulating the date, the tm_isdst is set to -1. > > >From https://cplusplus.com/reference/ctime/tm/: This site is notoriously sloppy if not outright wrong about pretty much everything. > The Daylight Saving Time flag (tm_isdst) is greater than zero if > Daylight Saving Time is in effect, zero if Daylight Saving Time is > not in effect, and less than zero if the information is not > available. The actual specification is at https://pubs.opengroup.org/onlinepubs/9699919799/functions/mktime.html (POSIX version; the C version is not independently linkable but says basically the same thing anyway). The relevant text, which differs from the above, is: "A negative value for tm_isdst shall cause mktime() to attempt to determine whether Daylight Savings Time is in effect for the specified time." No details are specified for how this determination is made, so it may differ between implementations. At DST transition boundaries, it's impossible to define unambiguously. There are either times that don't exist, or that could mean two different things. If there are cases where our current behavior isn't *consistent* (the input time does not match the output in either DST or non-DST), it seems like those should be treated as bugs and fixed. But if you're just expecting the implementation to guess whether your nonexistant time came from moving forward from non-DST or backward from DST, it can't; it just had to make an arbitrary choice, and that choice is not going to agree across different systems. > And the date should be correctly set as DST or STD in mktime. > > I have a date. I make change in fields, I set tm_isdst = -1, I call > mktime. If you already have a date and want a new date offset by some fixed amount of time from it, setting tm_isdst is wrong. You leave tm_isdst alone and adjust whichever field(s) (e.g. tm_min) you want to offset by, then call mktime. The resulting tm_isdst (and correspondingly other fields) may have changed if you crossed a DST boundary by making the offset. When you set tm_isdst=-1, you're throwing away information and explicitly asking the implementation to guess what an ambiguous timestamp meant. Does this help? Do you think there's an actual bug to be investigated on our side here? Rich