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-03-02 09:02 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'' ======================================================================
---------------------------------------------------------------------- (0006700) eggert (reporter) - 2024-03-02 09:02 https://austingroupbugs.net/view.php?id=1797#c6700 ---------------------------------------------------------------------- > 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. Although that’s true, we can use our best judgment about which programs will benefit. We know that there are programs that benefit from the resolution in Note: 0006689, because we have a bug report to that effect and it’s plausible there are more programs like that. Although these programs may not follow the strict reading of the standard, they’re plausible uses of the standard functions. In contrast, we don’t know of programs that would benefit from the resolution in Note: 0006691, and these programs are less plausible. > 2.... 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. Unfortunately it’s not reasonable. These apps are broken regardless of which resolution is taken, because the issue comes up with formats other than %s. Consider the following program, which simulates a user-specified format string containing "%Z" used to format a struct tm set by hand or by strptime: #include <stdio.h> #include <time.h> #include <string.h> int main (void) { char buf[1000]; struct tm tm; /* Make TM "uninitialized". */ memset (&tm, 0x81, sizeof tm); tm.tm_isdst = 0; strftime (buf, sizeof buf, "%Z", &tm); puts (buf); } This program dumps core on GNU/Linux, on FreeBSD, and I expect on pretty much any other implementation that supports TZDB-style struct tm, because it uses a bad pointer in tm.tm_zone. And yet the program conforms to POSIX.1-2017, which says that the call to strftime sets the buffer to some string. In other words, programmers can’t trust user-specified strftime formats on anything other than completely filled-in struct tm values, and that’s true regardless of what we do about %s. I suppose we could say that GNU/Linux, FreeBSD, and pretty much everyone else is broken. But it’s better to be realistic and tell users that when using strftime’s %z, %Z and %s formats, tm_zone and tm_gmtoff must be set to in-range values. Insisting on a pedantic reading based on older POSIX would not serve users well because it would give users the wrong impression of what code will actually work. > consider what system implementers will do We implementers will figure it out. It’s the user code that matters here anyway. 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 ======================================================================
