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:15 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'' ======================================================================
---------------------------------------------------------------------- (0006692) geoffclare (manager) - 2024-02-29 12:15 https://austingroupbugs.net/view.php?id=1797#c6692 ---------------------------------------------------------------------- I would prefer the resolution in https://austingroupbugs.net/view.php?id=1797#c6691 over the one in https://austingroupbugs.net/view.php?id=1797#c6689 (i.e. I think POSIX should not change to allow the new TZDB behaviour). I agree with the points kre made in https://austingroupbugs.net/view.php?id=1797#c6677 and in particular with the statement that we must not break apps which use strftime() %s without setting tm_gmtoff. The counter-argument that there are very few such apps does not hold water, for two reasons: 1. It is only possible to survey apps for which we have access to the source. We cannot know how many closed-source apps would be affected. 2. We should not consider only apps which use %s explicitly. There are also apps which use user-specified or configurable time format strings. Although a lot of these would be passing in a struct tm obtained from localtime() (as with, for example, GNU ls -l --time-style=+%s), passing one that is populated a different way is also a reasonable thing for an app to do. For example, it could store broken-down times in a standard format and want to present them to the user in their preferred format; to do this it could use strptime() followed by strftime(). Another point in favour of disallowing "blind" use of tm_gmtoff is to consider what system implementers will do when faced with the choice of how to handle a change in POSIX to allow it. In order to continue to support apps written for POSIX.1-2017 and earlier (which did not have tm_gmtoff and therefore conforming apps cannot set it directly) and also have the TZDB behaviour for apps written for POSIX.1-2024 and later, they would need to provide two different versions of strftime(), selected according to _POSIX_C_SOURCE or _XOPEN_SOURCE. It seems highly unlikely that any system implementers would bother to do that (it has been done in the past, but only when there was no choice); the new TZDB-like behaviour would therefore be rare and become a portability gotcha. 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 ======================================================================
