From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 038483858019; Tue, 12 Dec 2023 23:37:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 038483858019 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1702424222; bh=/CK6NN9dFolfDVMc5FrgS464XsCvr9bpU9c/pzJRHqk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=H3JrChBztuwDj64nfRDMOIsduJSr2SAQzW5LigU3tHtdXTXCMFNyIvkL45zELavus gEK+iThF0/NCIMEXdynoGJGGuJyRWsagWXRZJSnTi+JoIcVcDe7+BaHzYMKL93AXh0 mj1q2UVSjYXkgZJcpTsTLlQW9B4tdFh+/l7u76i0= From: "eggert at cs dot ucla.edu" To: glibc-bugs@sourceware.org Subject: [Bug time/31144] mktime: returns clock for UTC with isdst=1 Date: Tue, 12 Dec 2023 23:37:01 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: time X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: eggert at cs dot ucla.edu X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: NOTABUG X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D31144 eggert at cs dot ucla.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |NOTABUG --- Comment #2 from eggert at cs dot ucla.edu --- The C and POSIX standards do not specify what mktime should do with examples like this, so this is not a conformance issue. As Andreas mentioned, tm_isd= st is intended as a hint for ambiguous timestamps; unfortunately this does not suffice in general for TZDB Zones, e.g., 1971-10-31 02:30 when TZ=3D'Europe/London' because at 03:00 standard time moved back by an hour in London so there are two distinct matching timestamps both with tm_isdst=3D= =3D0, one with time_t=3D=3D57720600 and one with time_t=3D=3D57724200. So the whole a= rea is a bit of an ill-thought-out mess. glibc currently supports the idea that if you want to find a time that's 1 = year from now you can call localtime, add 1 to tm_year, and then call mktime on = the result, and you'll get a timestamp that's 1 year later or thereabouts (the concept of "one year later" is not well-defined). This idea didn't work with older glibc (and I guess FreeBSD libc?) if DST is in use now but not 1 year from now (or vice versa) because in those cases older glibc mktime simply failed. In practice the new glibc behavior seems to be more useful than the old one. The old behavior was changed in response to a real-world use case whereas the Erlang/OTP issue is an artificial = test case which is a weaker argument. With that in mind I'm going to resolve this as NOTABUG. The Erlang/OTP test case is wrong because it's making assumptions about mktime that are not pre= sent in the relative standards --=20 You are receiving this mail because: You are on the CC list for the bug.=