A NOTE has been added to this issue. ====================================================================== https://austingroupbugs.net/view.php?id=1797 ====================================================================== Reported By: eggert Assigned To: ====================================================================== Project: 1003.1(2024)/Issue8 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 Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2024-01-15 23:56 UTC Last Modified: 2024-10-10 15:27 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'' ======================================================================
---------------------------------------------------------------------- (0006908) geoffclare (manager) - 2024-10-10 15:27 https://austingroupbugs.net/view.php?id=1797#c6908 ---------------------------------------------------------------------- Interpretation Response ------------------------ The standard clearly states that when the input is in the normal range the strftime() %s conversion calculates the number of seconds since the Epoch as described for mktime(), and conforming implementations must conform to this. When the input is not in the normal range, the standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale: ------------- When the input is in the normal range: 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. When the input is not in the normal range: the standard states that the strftime() %s conversion calculates the number of seconds since the Epoch as described for mktime(), implying that out of range member values should be handled as for mktime(), but it also states ``If any of the specified values are outside the normal range, the characters stored are unspecified.'' Notes to the Editor (not part of this interpretation): ------------------------------------------------------- On page 452 lines 15753-15754 section XBD <time.h>, add CX shading to the lines for tm_gmtoff and tm_zone. On page 1211 line 41369 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_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 41385 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 1427 line 47885 section mktime(), change: <blockquote>The <i>mktime</i>() function shall make use of only the <i>tm_year, tm_mon, tm_mday, tm_hour, tm_min, tm_sec,</i> and <i>tm_isdst</i> members of the structure pointed to by <i>timeptr</i>; the values of these members shall not be restricted to the ranges described in <b><time.h></b>.</blockquote> to: <blockquote>The <i>mktime</i>() function shall make use of only the <i>tm_year, tm_mon, tm_mday, tm_hour, tm_min, tm_sec,</i> and <i>tm_isdst</i> members of the structure pointed to by <i>timeptr</i>, <CX>except that <i>tm_gmtoff</i> may also be used in order to choose between two valid return values, provided it can be used safely if uninitialized</CX>; the values of these members shall not be restricted to the ranges described in <b><time.h></b>.</blockquote> On page 1428 line 47952 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 2134 line 69724 section strftime(), change: <blockquote>The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of POSIX.1-2024 defers to the ISO C standard.</blockquote> to: <blockquote>Except for the members of the <b>tm</b> structure used by the <tt>z</tt> and <tt>Z</tt> conversion specifiers (see below), the functionality described on this reference page is aligned with the ISO C standard. Any other conflict between the requirements described here and the ISO C standard is unintentional. This volume of POSIX.1-2024 defers to the ISO C standard for all <i>strftime</i>() functionality except in relation to this aspect of the <tt>z</tt> and <tt>Z</tt> conversion specifiers.</blockquote> On page 2135 line 69760 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 69764 section strftime(), change: <blockquote>Local timezone information shall be set as though <i>strftime</i>() called <i>tzset</i>().</blockquote> to: <blockquote>It is implementation-defined whether local timezone information is set as though <i>strftime</i>() called <i>tzset</i>().</blockquote> On page 2136 line 69823 section strftime() (%s), 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>(), except that the <b>tm</b> structure member values used by this conversion need to be within the normal range, as if set by <i>localtime</i>(), to avoid unspecified output. [<i>tm_year, tm_mon, tm_mday, tm_hour, tm_min, tm_sec, tm_isdst, tm_gmtoff</i>]</blockquote> On page 2137 line 69854 section strftime() (%z), change: <blockquote><CX>If <i>tm_isdst</i> is zero, the standard time offset is used. If <i>tm_isdst</i> is greater than zero, the daylight saving time offset is used. If <i>tm_isdst</i> is negative, no characters are returned.</CX> [<i>tm_isdst, <CX>tm_gmtoff</CX></i>]</blockquote> to: <blockquote>[<CX>tm_gmtoff</CX></i>]</blockquote> On page 2137 line 69858 section strftime() (%Z), change: <blockquote>Replaced by the timezone name or abbreviation, or by no bytes if no timezone information exists. [<i>tm_isdst, <CX>tm_zone</CX></i>]</blockquote> to: <blockquote>Replaced by the timezone name or abbreviation, or by no bytes if no timezone information exists. <CX>If the <i>tm_zone</i> value was not set by one of the standard functions that set it, the application shall ensure that it is either a null pointer (indicating that no timezone information exists) or points to a string containing the timezone name or abbreviation. [<i>tm_zone</i>].</CX></blockquote> On page 2137 line 69862 section strftime(), change: <blockquote>If a <b>struct tm</b> broken-down time structure is created by <i>localtime</i>() or <i>localtime_r</i>(), or modified by <i>mktime</i>(), and the value of <i>TZ</i> is subsequently modified, the results of the <tt>%Z</tt> and <tt>%z</tt> <i>strftime</i>() conversion specifiers are undefined, when <i>strftime</i>() is called with such a broken-down time structure. If a <b>struct tm</b> broken-down time structure is created or modified by <i>gmtime</i>() or <i>gmtime_r</i>(), it is unspecified whether the result of the <tt>%Z</tt> and <tt>%z</tt> conversion specifiers shall refer to UTC or the current local timezone, when <i>strftime</i>() is called with such a broken-down time structure.</blockquote> to: <blockquote>If a <b>struct tm</b> broken-down time structure is created by <i>localtime</i>() or <i>localtime_r</i>(), or modified by <i>mktime</i>(), and the value of <i>TZ</i> is subsequently modified, the results of the <tt>Z</tt> <i>strftime</i>() conversion specifier are undefined, when <i>strftime</i>() is called with such a broken-down time structure.</blockquote> After page 2139 line 69953 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, %z, and %Z conversion of <i>strftime</i>() is not portable unless local time is UTC, as the implementation might process the conversions either by inspecting the structure’s <i>tm_gmtoff</i> and <i>tm_zone</i> members, or by inspecting global state.</blockquote> After page 2142 line 70092 section strftime(), add a new paragraph to RATIONALE: <blockquote>The ISO C standard specifies that the <tt>z</tt> and <tt>Z</tt> conversion specifiers use only the <i>tm_isdst</i> member of the <b>tm</b> structure, whereas POSIX.1 implementations have the additional structure members <i>tm_gmtoff</i> and <i>tm_zone</i> which provide information used in these conversions. Therefore this standard does not defer to the ISO C standard in relation to this aspect of the <tt>z</tt> and <tt>Z</tt> conversion specifiers. A future version of the ISO C standard is expected to allow the use of ``all members, including any non-standard additional members''.</blockquote> On page 2376 line 77023 section wcsftime(), change: <blockquote>The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of POSIX.1-2024 defers to the ISO C standard.</blockquote> to: <blockquote>Except for the members of the <b>tm</b> structure used by the <tt>z</tt> and <tt>Z</tt> conversion specifiers (see [xref to strftime()]), the functionality described on this reference page is aligned with the ISO C standard. Any other conflict between the requirements described here and the ISO C standard is unintentional. This volume of POSIX.1-2024 defers to the ISO C standard for all <i>wcsftime</i>() functionality except in relation to this aspect of the <tt>z</tt> and <tt>Z</tt> conversion specifiers.</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 2024-02-29 12:15 geoffclare Note Added: 0006692 2024-02-29 16:19 shware_systems Note Added: 0006693 2024-03-01 10:09 geoffclare Note Added: 0006698 2024-03-02 09:02 eggert Note Added: 0006700 2024-03-03 01:20 kre Note Added: 0006701 2024-03-07 10:44 geoffclare Note Added: 0006706 2024-03-07 11:04 geoffclare Note Added: 0006707 2024-03-11 09:55 geoffclare Note Added: 0006718 2024-05-23 08:04 eggert Note Added: 0006793 2024-05-23 08:07 eggert Note Added: 0006794 2024-05-23 10:47 geoffclare Note Added: 0006795 2024-05-23 16:57 kre Note Added: 0006797 2024-05-24 18:59 eggert Note Added: 0006798 2024-05-24 21:32 kre Note Added: 0006799 2024-05-24 22:56 eggert Note Added: 0006801 2024-05-25 17:12 kre Note Added: 0006802 2024-10-10 15:25 geoffclare Project Issue 8 drafts => 1003.1(2024)/Issue8 2024-10-10 15:27 geoffclare Note Added: 0006908 ======================================================================
