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-05-24 21:32 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'' ======================================================================
---------------------------------------------------------------------- (0006799) kre (reporter) - 2024-05-24 21:32 https://austingroupbugs.net/view.php?id=1797#c6799 ---------------------------------------------------------------------- Re https://austingroupbugs.net/view.php?id=1797#c6798 But we are talking about what strftime should do with struct tm values outside the normal range. No, we aren't. strftime() is clear the results are unspecified if the relevant fields aren't within the normal range(s). You can do what you like in that case (but only the relevant fields, when converting %a for example, it isirrelevant what tn_mday or tm_mon or ... are set to, just tm_wday). The same goes for all of the conversions. The C standard says that strftime can consult tm_isdst for %Z. I don't have that one in front of me, but I doubt it says anything much different than posix says, which is: The appropriate characters are determined using the LC_TIME category of the current locale and by the values of zero or more members of the broken-down time structure pointed to by timeptr, as specified in brackets in the description. What that means is that the specified fields of the struct tm (the "broken-down time structure") are all that the application needs to ensure are set in order to perform a specific conversion. While you're certainly correct that the implementation can look at other data, that other data cannot come from the struct, as there's no expectation that any of that will have been set by the application, and there's no field in the struct (which would need to be some kind of checksum to detect changes to other fields made by the application) by which it is possible to determine that other fields have consistent values with the fields of interest to the conversion. But yes, you can certainly use what is in TZ, or anything obtained from its use, and anything you can get from the LC_TIME locale. And while: tm_zone is an extension to the C standard and the C standard has nothing to say about what tm_zone’s contents can or should be. is certainly true, this conclusion: And requiring tm_zone to have sensible contents is not a violation either: is incorrect. A conforming C application cannot set tm_zone as no such thing exists. Hence an implementation which is supposed to support conforming C applications cannot use data from that field, as it has no way to know if anything is there or not (or anything relevant for sure). The implementation is certainly allowed to set that field (as in localtime() for example), a conforming application will never look there, and so will never care if it is set or not. POSIX is intended to support conforming C applications. And finally: When the standard isn’t clear on a matter it’s better to clear it up; That's right, but in this case it is clear. Always has been (even if the wording was a bit bizarre in some places). Furthermore, since this affects C programs, it should be fixed, if any fixing is needed, by the C standard first, not by some end-run performed here. 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 2024-05-23 10:47 geoffclare Note Added: 0006795 2024-05-23 16:57 kre Note Added: 0006797 2024-05-24 18:59 eggert Note Added: 0006798 2024-05-24 21:32 kre Note Added: 0006799 ======================================================================
