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-12 16:11 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) ... ======================================================================
---------------------------------------------------------------------- (0006651) eblake (manager) - 2024-02-12 16:11 https://austingroupbugs.net/view.php?id=1797#c6651 ---------------------------------------------------------------------- Feedback from Paul Eggert via email: On 2024-02-05 08:15, Eric Blake wrote: > Did you consider the effect of the change on applications that > populate struct tm directly (and don't currently set tm_gmtoff, except > perhaps by zeroing the structure)? Yes. Very few apps do that. (I looked for some in the GNU code I help maintain, and found none.) They are greatly outnumbered by the applications that call localtime/localtime_r/mktime/gmtime/gmtime_r/etc. and pass the result to strftime, which is what this bug report is about. > Does the latest tzdata code only use tm_gmtoff in the rare cases when > it is necessary for disambiguation, or is it always used (overriding > the timezone data)? The bug description implies the former, but the > desired action would allow the latter. The former. That is, TZDB 2024a strftime looks only at tm_gmtoff, tm_year, tm_mon, tm_day, tm_hour, tm_min, and tm_sec to determine %s, because that's all you need. The desired action allows either the TZDB behavior, or the glibc behavior which if I recall consults tm_gmtoff only when tm_isdst is ambiguous. The TZDB behavior is technically better than the glibc behavior for three reasons: (1) it removes a multithreading bottleneck, (2) even in a single-threaded platform it's faster because mktime is slower than using tm_gmtoff, and (3) when user code mistakenly calls gmtime and then strftime then %s does what the user expects. The bug report that caused TZDB to behave this way was about (3), but (1) and (2) also play a part. 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 ======================================================================
