A NOTE has been added to this issue. ====================================================================== https://austingroupbugs.net/view.php?id=1613 ====================================================================== Reported By: kre Assigned To: ====================================================================== Project: Issue 8 drafts Issue ID: 1613 Category: System Interfaces Type: Omission Severity: Objection Priority: normal Status: New Name: Robert Elz Organization: User Reference: Section: XSH 3/mktime Page Number: 1311 Line Number: 43850-43854, 43865-43866, 43867-43870 Final Accepted Text: ====================================================================== Date Submitted: 2022-11-03 12:53 UTC Last Modified: 2022-11-03 20:21 UTC ====================================================================== Summary: XSH 3/mktime was not updated by the resolution of bug 1533, but should have been (++) ======================================================================
---------------------------------------------------------------------- (0006029) kre (reporter) - 2022-11-03 20:21 https://austingroupbugs.net/view.php?id=1613#c6029 ---------------------------------------------------------------------- Re https://austingroupbugs.net/view.php?id=1613#c6023 Steffen, just ignore the NetBSD mailing list thread, that's just a couple of people (one really) who have no idea at all what they're talking about and are proposing utter nonsense which will never happen. That's gibberish. I know the line you quoted from the standard (which is in both mktime() and strftime()) about calling tzset (that applies to the NetBSD list discussion - though the people there don't care what POSIX specifies, just that those functions do what they are presuming that they should always do ... I intend to post one last time there, soon, if things have finally calmed dowm and both include that line from the standard, and show the fringe that NetBSD already has (non-POSIX) interfaces that do exactly what they want, which are in our manual pages, which they are obviously not bothering to read, but while things are running hot, that would not go down well). You may be correct that musl's broken (non-conforming) implementation here may have been what triggered that discussion originally, but isn't what added the heat. I don't think discussing implementation code details is really appropriate here however. But that line doesn't impact this current issue - there's no question but that mktime() (and strftime) are required to treat the time as local time, but local time can have more than one tm_gmtoff (and does, in any zone when summer time applies) - and an implementation could use tm_gmtoff to help it select which of the ambiguous time values in the "end of summer time, time runs twice" situation. My point here is that implementations must not do that, as doing so can cause existing conforming applications to produce undefined behaviour. While I am here, I see a line in the "Desired action" where I managed to make two typos... (but neither of the form a spell checker can detect). The line: structure pointer to by timeptr, which values shall not be restricted should have said structure pointed to by timeptr, in which values shall not be restricted Regular users are able to edit their own notes, like this one, but not the problem description, nor desired action, so ... Issue History Date Modified Username Field Change ====================================================================== 2022-11-03 12:53 kre New Issue 2022-11-03 12:53 kre Name => Robert Elz 2022-11-03 12:53 kre Section => XSH 3/mktime 2022-11-03 12:53 kre Page Number => 1311 2022-11-03 12:53 kre Line Number => 43850-43854, 43865-43866, 43867-43870 2022-11-03 17:56 steffen Note Added: 0006023 2022-11-03 20:21 kre Note Added: 0006029 ======================================================================
