A NOTE has been added to this issue. ====================================================================== https://austingroupbugs.net/view.php?id=1727 ====================================================================== Reported By: kre Assigned To: ====================================================================== Project: Issue 8 drafts Issue ID: 1727 Category: System Interfaces Type: Enhancement Request Severity: Objection Priority: normal Status: New Name: Robert Elz Organization: User Reference: Section: XSH 3 / strptime Page Number: 2146-7 Line Number: 70221-2, 70250-7 Final Accepted Text: ====================================================================== Date Submitted: 2023-05-14 19:23 UTC Last Modified: 2023-05-15 14:25 UTC ====================================================================== Summary: strptime() spec needs updates to deal with other changes. ======================================================================
---------------------------------------------------------------------- (0006285) kre (reporter) - 2023-05-15 14:25 https://austingroupbugs.net/view.php?id=1727#c6285 ---------------------------------------------------------------------- In addition, at lines 70311-2 If a match is found, values for the appropriate tm structure members are set to values corresponding to the locale information. The specification is missing an indication of which tm structure members are "appropriate" ... you'd think it would be obvious, but apparently not. This should be changed to say "values for the indicated tm structure members" (ie: s/appropriate/indicated/) and each conversion specification description (lines 70180 - 70257) should be updated to indicate, in a way similar to is done with strftime() exactly which fields are to be updated, when any are so required. I don't think it is important whether the combination conversion specs (eg: %T is %H:%M:%S) explicitly list the (in that case, three) fields to be updated, or if the text just makes it clear that having %T in the format must produce the same results as specifying %H:%M:%S and defer to the specifications for each of those. For the harder ones (maybe just %c) we don't know what the equivalent will be (that's defined by the locale, though like is done with %r, the definition for the POSIX locale should probably be given) so deferring in that case is really the only way. The description of the %c conversion (which looks like it was just cut & paste from strftime) should probably be updated anyway. It would be better if the specification for that one was more like %c Equivalent to a locale specified sequence of other directives. In the POSIX locale, it shall be equivalent to "....". Beyond that, the %p conversion specification specification (no, that isn't redundant) is useless as it is. Sure, it scans the locale's am/pm indicator, but what if there is no such thing? Further, once having done that, what happens, if anything. I'd expect that it should include something like If the format string has previously scanned a representation of the hour (%H or %I) and if the locale's representation of the p.m. indicator was scanned by %p and the value previously scanned for the hour was in the range [0,11] then 12 shall be added to that value, otherwise no change shall be made. (And indicate this effects tm_hour). Similarly The %r conversion specification should indicate what happens if the locale doesn't support 12 hour clocks - application developers have no idea what locale the user will use after all. I'd expect that in that case %r would be the same as %T but I don't know if that is what implementations do. Lastly, at least for now, is it really correct now for %C and %Y to specify {2} and {4} respectively? Doesn't the spec for strftime() allow for years beyond 9999 (and even before 0)? If the year were 12345 when output by strftime, then when scanned by strptime, stopping at 1234 can't be correct, can it? Similarly, %C should produce 123 not 12. to the hour field. Issue History Date Modified Username Field Change ====================================================================== 2023-05-14 19:23 kre New Issue 2023-05-14 19:23 kre Name => Robert Elz 2023-05-14 19:23 kre Section => XSH 3 / strptime 2023-05-14 19:23 kre Page Number => 2146-7 2023-05-14 19:23 kre Line Number => 70221-2, 70250-7 2023-05-15 14:25 kre Note Added: 0006285 ======================================================================
