A NOTE has been added to this issue. ====================================================================== https://www.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-05-23 08:07 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'' ======================================================================
---------------------------------------------------------------------- (0006794) eggert (reporter) - 2024-05-23 08:07 https://www.austingroupbugs.net/view.php?id=1797#c6794 ---------------------------------------------------------------------- Although the resolution proposed in Note: 0006691 has a lot to like, we need to do better with %s, %z, and %Z, as discussed in my previous comment. One thing that’s not clearly nailed down is that the implementation should be consistent in this area. That is, whatever it does for %s should be consistent with what it does for %z, and likewise for %Z. This is a “should” not a “must” because not every implementation is consistent, but intuitively it makes sense that the three formats should expand to consistent output. Interpretation response ------------------------ The standard 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. However, concerns have been raised about this which are being referred to the sponsor. Rationale: ------------- In previous editions of POSIX, struct tm lacked tm_gmtoff and tm_zone members, so strftime needed to inspect global state to process %z and %Z. The current version allows strftime to instead inspect tm_gmtoff for %z, and tm_zone for %Z, as is common practice. For consistency it also allows strftime to inspect tm_gmtoff to process %s, a newly-required format. A strftime that inspects tm_gmtoff and tm_zone works better with applications that use geographical timezones, or that fill in struct tm members by calling gmtime or equivalent. Conversely, a strftime that inspects global state is more compatible with previous editions of POSIX when programs use the second TZ format in XBD Section 8.3 and fill in struct tm members individually without calling localtime or equivalent. A strftime implementation can do both: that is, it can inspect global state when the second TZ format is used, and use tm_gmtoff and tm_zone when a geographical timezone is used. This edition of the standard does not say whether the abovementioned global state consists of the contents of the variables tzname and timezone, or some other part of the system state that user code cannot modify directly. Modifying tzname and timezone therefore might (but might not) affect the global state that in turn might affect strftime’s behavior with %s, %z, and %Z, or might not if strftime inspects tm_gmtoff and tm_zone instead. Regardless of implementation method, implementations should process the conversion specifications %s, %z, and %Z consistently. For example, if strftime uses tm_gmtoff to process %z, it should also use tm_gmtoff to process %s and should use tm_zone to process %Z. Conversely, if strftime uses global state to determine one of the the three conversion specifications, it should use the same global state to determine the other two. 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 tm_gmtoff and tm_zone. On page 1211 line 41381 section gmtime() DESCRIPTION, change (already in CX shading): ...where the names in the structure and in the expression correspond. to: ...where the names in the structure and in the expression correspond; additionally, the tm_gmtoff field of the struct tm shall be set to 0, and the tm_zone field shall be set to a pointer to an implementation-defined string set to "UTC" or "GMT", which shall have static storage duration. On page 1211 line 41397 section gmtime() RETURN VALUE, delete: The structure’s tm_zone member shall be set to a pointer to the string "UTC", which shall have static storage duration. On page 1428 line 47958 section mktime(), change: 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. to: 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; mktime() may use the value of tm_gmtoff to decide which of these two results is the more appropriate to return, provided it can do so safely if tm_gmtoff is uninitialized. On page 2135 line 69773 section strftime(), change: If any of the specified values are outside the normal range, the characters stored are unspecified. to: If any of the specified values are outside the normal range, as if set by localtime(), the characters stored are unspecified. On page 2135 line 69777 section strftime(), change: Local timezone information shall be set as though strftime() called tzset(). to: It shall be implementation-defined whether local timezone information is set as though strftime() called tzset(). On page 2136 line 69836 section strftime(), change: Replaced by the number of seconds since the Epoch as a decimal number, calculated as described for mktime(). [tm_year, tm_mon, tm_mday, tm_hour, tm_min, tm_sec, tm_isdst] to: Replaced by the number of seconds since the Epoch as a decimal number, calculated as described for mktime(). Note that, unlike mktime(), the tm structure member values used by this conversion need to be within the normal range, as if set by localtime(), to avoid unspecified output. [tm_year, tm_mon, tm_mday, tm_hour, tm_min, tm_sec, tm_isdst, tm_gmtoff] After page 2140 line 70007 section strftime(), add a new paragraph to APPLICATION USAGE: Using a tm structure populated by gmtime() or gmtime_r() with the %s, %z, and %Z conversion of strftime() is not portable unless local time is UTC, as the implementation might process the conversions either by inspecting the structure’s tm_gmtoff and tm_zone members, or by inspecting global state. 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 ======================================================================
