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-25 06:50 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) ... ======================================================================
---------------------------------------------------------------------- (0006677) kre (reporter) - 2024-02-25 06:50 https://austingroupbugs.net/view.php?id=1797#c6677 ---------------------------------------------------------------------- I do not like this proposed change - as strftime(%s) is specified in the drafts for Issue 8 is just fine - it and mktime() always produce the same value, given the same (in range) values in the struct tm passed to them. Never anything different. The change that was made to the tzcode implementation to use tm_gmtoff (which despite what was said on the list, is always used if it exists - in that implementation what TZ is set to is immaterial to strftime(%s)) was based upon a user hope for what would happen (to get back the time_t that was used to produce a particular struct tm) completely ignoring that no such invocation is required to have occurred. strftime() simply formats as text values from the struct tm which the format string requests - regardless of how those values were inserted. The "very few apps" which "do that" must not be broken by a change like this. Applications which call gmtime() and then strftime(%s) upon the result, and expect the (formatted as a string) value that was used as gmtime()'s arg to be produced are simply broken. (That usage was exactly what led to the "bug" report that was "fixed" by the tzcode change - nonsense.) Simply reject this "bug". I'd also note that while NetBSD has the 2024a version of tzcode (in HEAD anyway) the change that was made to strftime(%s) in that release was reverted, we still do things the old way, using TZ, not using tm_gmtoff. 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 ======================================================================
