A NOTE has been added to this issue. ====================================================================== https://austingroupbugs.net/view.php?id=1797 ====================================================================== Reported By: eggert Assigned To: ====================================================================== Project: Issue 8 drafts Issue ID: 1797 Category: System Interfaces Type: Error Severity: Objection Priority: normal Status: New Name: Paul Eggert Organization: UCLA Computer Science Dept. User Reference: strftime-%s Section: strftime Page Number: 2136 Line Number: 69836-69837 Final Accepted Text: ====================================================================== Date Submitted: 2024-01-15 23:56 UTC Last Modified: 2024-02-29 12:10 UTC ====================================================================== Summary: strftime "%s" should be able to examine tm_gmtoff ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- related to 0001533 struct tm: add tm_gmtoff (and tm_zone) ... related to 0001816 daylight, timezone, tzname do not work ... child of 0001612 XSH strftime() new (I8) %s conversion r... child of 0000169 date utility needs ``%s'' ======================================================================
---------------------------------------------------------------------- (0006691) geoffclare (manager) - 2024-02-29 12:10 https://austingroupbugs.net/view.php?id=1797#c6691 ---------------------------------------------------------------------- The following is an alternative resolution to be considered, which retains the requirement for strftime() %s to give the same result as mktime() (for in-range struct tm field values). It does allow strftime() %s - and mktime() - to make use of tm_gmtoff, but only as a means to choose between two valid results. It also includes fixes for the various other related issues raised during the discussion to far. Interpretation response ------------------------ The standard clearly states that the strftime() %s conversion calculates the number of seconds since the Epoch as described for mktime(), and conforming implementations must conform to this. Rationale: ------------- There is no requirement for applications to set the tm_gmtoff member and therefore implementations cannot rely on it having been set. However, in situations where there are two valid results of the conversion, an implementation may choose to make use of tm_gmtoff to decide between these two values (provided it can do so safely if tm_gmtoff is uninitialized), even though the strftime() %s conversion is not specified as making use of tm_gmtoff, since returning either of the values is allowed by the standard and the method used to choose between them is internal implementation detail that does not affect applications. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- Using draft 4.0 line numbering: On page 452 lines 15762-15763 section XBD <time.h>, add CX shading to the lines for <i>tm_gmtoff</i> and <i>tm_zone</i>. On page 1211 line 41381 section gmtime() DESCRIPTION, change (already in CX shading): <blockquote>...where the names in the structure and in the expression correspond.</blockquote> to: <blockquote>...where the names in the structure and in the expression correspond; additionally, the <i>tm_gmtoff</i> field of the struct <b>tm</b> shall be set to 0, and the <i>tm_zone</i> field shall be set to a pointer to an implementation-defined string set to "UTC" or "GMT", which shall have static storage duration.</blockquote> On page 1211 line 41397 section gmtime() RETURN VALUE, delete: <blockquote>The structure’s <i>tm_zone</i> member shall be set to a pointer to the string "UTC", which shall have static storage duration.</blockquote> On page 1428 line 47958 section mktime(), change: <blockquote>shall calculate the time since the Epoch value using either the offset in effect before the change or the offset in effect after the change.</blockquote> to: <blockquote>shall calculate the time since the Epoch value using either the offset in effect before the change or the offset in effect after the change; <i>mktime</i>() may use the value of <i>tm_gmtoff</i> to decide which of these two results is the more appropriate to return, provided it can do so safely if <i>tm_gmtoff</i> is uninitialized.</blockquote> On page 2135 line 69773 section strftime(), change: <blockquote>If any of the specified values are outside the normal range, the characters stored are unspecified.</blockquote> to: <blockquote>If any of the specified values are outside the normal range, as if set by <i>localtime</i>(), the characters stored are unspecified.</blockquote> On page 2135 line 69777 section strftime(), change: <blockquote>Local timezone information shall be set as though <i>strftime</i>() called <i>tzset</i>().</blockquote> to: <blockquote>It shall be implementation-defined whether local timezone information is set as though <i>strftime</i>() called <i>tzset</i>().</blockquote> On page 2136 line 69836 section strftime(), change: <blockquote>Replaced by the number of seconds since the Epoch as a decimal number, calculated as described for <i>mktime</i>(). [<i>tm_year, tm_mon, tm_mday, tm_hour, tm_min, tm_sec, tm_isdst</i>]</blockquote> to: <blockquote>Replaced by the number of seconds since the Epoch as a decimal number, calculated as described for <i>mktime</i>(). Note that, unlike <i>mktime</i>(), the <b>tm</b> structure member values used by this conversion, other than <i>tm_gmtoff</i>, need to be within the normal range, as if set by <i>localtime</i>(), to avoid unspecified output; the value of <i>tm_gmtoff</i> can be uninitialized (see [xref to mktime()]). [<i>tm_year, tm_mon, tm_mday, tm_hour, tm_min, tm_sec, tm_isdst, tm_gmtoff</i>]</blockquote> After page 2140 line 70007 section strftime(), add a new paragraph to APPLICATION USAGE: <blockquote>Using a <b>tm</b> structure populated by <i>gmtime</i>() or <i>gmtime_r</i>() with the %s conversion of <i>strftime</i>() should be avoided, as the calculated seconds since the Epoch value will only correspond to the specified broken-down time if the offset from UTC of the local timezone happens to be zero at that time.</blockquote> Issue History Date Modified Username Field Change ====================================================================== 2024-01-15 23:56 eggert New Issue 2024-01-15 23:56 eggert Name => Paul Eggert 2024-01-15 23:56 eggert Organization => UCLA Computer Science Dept. 2024-01-15 23:56 eggert User Reference => strftime-%s 2024-01-15 23:56 eggert Section => strftime 2024-01-15 23:56 eggert Page Number => 2136 2024-01-15 23:56 eggert Line Number => 69836-69837 2024-01-16 01:29 steffen Note Added: 0006623 2024-01-16 01:42 steffen Note Added: 0006624 2024-01-16 01:42 steffen Note Deleted: 0006623 2024-02-01 16:42 nick Relationship added related to 0001533 2024-02-12 16:11 eblake Note Added: 0006651 2024-02-25 06:50 kre Note Added: 0006677 2024-02-25 06:54 kre Note Edited: 0006677 2024-02-26 18:28 eggert Note Added: 0006688 2024-02-26 19:23 eblake Relationship added related to 0001816 2024-02-26 19:32 eblake Note Added: 0006689 2024-02-26 19:52 eblake Relationship added child of 0001612 2024-02-26 19:55 eblake Relationship added child of 0000169 2024-02-26 20:02 eblake Note Added: 0006690 2024-02-29 12:10 geoffclare Note Added: 0006691 ======================================================================
