0001727: strptime() spec needs updates to deal with other changes.

Notes
(0006285) kre (reporter) 2023-05-15 14:25 edited on: 2023-05-15 14:28	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.

(0006286) geoffclare (manager) 2023-05-16 08:57	> If the year were 12345 when output by strftime, then when scanned by strptime, stopping at 1234 can't be correct, can it? Yes it can, and the rationale for strftime has a table which includes exactly this example for %Y format.

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
2023-05-15 14:28	kre	Note Edited: 0006285
2023-05-16 08:57	geoffclare	Note Added: 0006286

Relationships

Aardvark Mark IV