Austin Group Defect Tracker

Aardvark Mark IV

Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001727 [Issue 8 drafts] System Interfaces Objection Enhancement Request 2023-05-14 19:23 2023-05-16 08:57
Reporter kre View Status public  
Assigned To
Priority normal Resolution Open  
Status New   Product Version Draft 3
Name Robert Elz
User Reference
Section XSH 3 / strptime
Page Number 2146-7
Line Number 70221-2, 70250-7
Final Accepted Text
Summary 0001727: strptime() spec needs updates to deal with other changes.
Description When tm_gmtoff and tm_zone were added to struct tm, the %z and %Z
conversions of strptime() should really have been updated to deal
with them.

And while here, the (CX shaded) %s conversion gives no clue at all
about what effect it might have on the struct tm (unlike say %g %G ^U...)

Desired Action Around lines 70221-2 (the %s definition) and withinh the CX shading, add
words similar to those used elsewjere (eg: %g)

    The effect of this number, if any, on the tm structure pointed to by
    tm is unspecified.

For %z, lines 70250-2 the statement that is currently there, just like the
ones that should be added for %s, should be deleted (as in the tm_gmtoff
field will now be set to the value parsed by %z).

For %Z. lines 70253-7 the similar statement should also be removed, but this
one probably needs some investigation as to what can be said about what is
done with tm_zone - does it get set to point info the value pointed to by
the buf arg to strptime() or does that get copied - to static storage, or
dynamic, and if the latter, who frees it ? I have no idea. But simply
pretending that tm_zone still doesn't exist cannot be correct.
Tags No tags attached.
Attached Files

- Relationships

-  Notes
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.

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

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker