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 2024-06-11 09:12
Reporter kre View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Closed   Product Version Draft 3
Name Robert Elz
Organization
User Reference
Section XSH 3 / strptime
Page Number 2146-7
Line Number 70221-2, 70250-7
Final Accepted Text Note: 0006384
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 applied_after_i8d3, issue8
Attached Files

- Relationships

-  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.
(0006383)
geoffclare (manager)
2023-07-13 09:54

> 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

I checked glibc, FreeBSD, and Illumos; none of them set tm_zone.

> does it get set to point into 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.

I would not be surprised if this issue is precisely why they don't set tm_zone.
(0006384)
geoffclare (manager)
2023-07-13 15:17

On page 2145 line 70181 section strptime() (%a), append:
The tm_wday member of the tm structure pointed to by tm shall be set to the corresponding day of the week number (Sunday=0).


On page 2146 line 70184 section strptime() (%b), append:
The tm_mon member of the tm structure pointed to by tm shall be set to the corresponding month number.


On page 2146 line 70186 section strptime() (%c), append:
The members of the tm structure pointed to by tm shall be set as specified for the conversions present in the locale's d_t_fmt value.


On page 2146 line 70189 section strptime() (%C), append:
The tm_year member of the tm structure pointed to by tm shall be set to the number formed by appending the last two digits of the year to these digits, minus 1900. If a <tt>y</tt> conversion is also performed, the last two digits of the year shall be those processed by the <tt>y</tt> conversion; otherwise, they shall be 00.


On page 2146 line 70190 section strptime() (%d), append:
The tm_mday member of the tm structure pointed to by tm shall be set to this number.


On page 2146 line 70191 section strptime() (%D), change:
The date as <tt>%m/%d/%y</tt>.

to:
Equivalent to <tt>%m/%d/%y</tt>.


On page 2146 line 70198 section strptime() (%F), append:
The members of the tm structure pointed to by tm shall be set as specified for the <tt>Y</tt>, <tt>m</tt>, and <tt>d</tt> conversions.


On page 2146 line 70209 section strptime() (%H), append:
The tm_hour member of the tm structure pointed to by tm shall be set to this number.


On page 2146 line 70211 section strptime() (%I), append:
If a <tt>p</tt> conversion is also performed, the tm_hour member of the tm structure pointed to by tm shall be set to the hour, by the 24-hour clock, corresponding to the combined results of the <tt>I</tt> and <tt>p</tt> conversions. If a <tt>p</tt> conversion is not also performed, the behavior is unspecified.


On page 2146 line 70213 section strptime() (%j), append:
The tm_yday member of the tm structure pointed to by tm shall be set to this number minus 1.


On page 2146 line 70214 section strptime() (%m), append:
The tm_mon member of the tm structure pointed to by tm shall be set to this number minus 1.


On page 2146 line 70215 section strptime() (%M), append:
The tm_min member of the tm structure pointed to by tm shall be set to this number.


On page 2146 line 70217 section strptime() (%p), append:
If an <tt>I</tt> conversion is also performed, the tm_hour member of the tm structure pointed to by tm shall be set as specified for the <tt>I</tt> conversion; otherwise, the behavior is unspecified.


On page 2146 line 70219 section strptime() (%r), append:
The members of the tm structure pointed to by tm shall be set as specified for the conversions present in the locale's t_fmt_ampm value.


On page 2146 line 70220 section strptime() (%R), change:
The time as <tt>%H:%M</tt>.

to:
Equivalent to <tt>%H:%M</tt>.


On page 2146 line 70222 section strptime() (%s), add a sentence:
The effect of this number, if any, on the tm structure pointed to by tm is unspecified.

and remove the CX shading from the description of the s conversion.

On page 2147 line 70223 section strptime() (%S), append:
The tm_sec member of the tm structure pointed to by tm shall be set to this number.


On page 2147 line 70225 section strptime() (%T), change:
The time as <tt>%H:%M:%S</tt>.

to:
Equivalent to <tt>%H:%M:%S</tt>.


On page 2147 line 70226 section strptime() (%u), append:
The tm_wday member of the tm structure pointed to by tm shall be set to this number modulo 7.


On page 2147 line 70233 section strptime() (%w), append:
The tm_wday member of the tm structure pointed to by tm shall be set to this number.


On page 2147 line 70237 section strptime() (%x), append:
The members of the tm structure pointed to by tm shall be set as specified for the conversions present in the locale's d_fmt value.


On page 2147 line 70238 section strptime() (%X), append:
The members of the tm structure pointed to by tm shall be set as specified for the conversions present in the locale's t_fmt value.


On page 2147 line 70238 section strptime() (%y), change:
When format contains neither a <tt>C</tt> conversion specifier nor a <tt>Y</tt> conversion specifier, values in the range ...

to:
If a <tt>C</tt> conversion is not also performed, values in the range ...


On page 2147 line 70243 section strptime() (%y), append:
If a <tt>C</tt> conversion is also performed, the tm_year member of the tm structure pointed to by tm shall be set as specified for the <tt>C</tt> conversion; otherwise, the tm_year member shall be set to the calculated year minus 1900.


On page 2147 line 70249 section strptime() (%Y), append:
The tm_year member of the tm structure pointed to by tm shall be set to this number minus 1900.


On page 2147 line 70251 section strptime() (%Z), change:
If this name matches tzname[1], and tzname[0] and tzname[1] differ, then the tm_isdst field of the tm structure pointed to by tm shall be set to 1. Otherwise, if this name matches tzname[0] then the tm_isdst field of the tm structure pointed to by tm shall be set to 0. Any other effects on the tm structure pointed to by tm are unspecified.

to:
If this name matches the name pointed to by tzname[1], and the names pointed to by tzname[0] and tzname[1] differ, then the tm_isdst member of the tm structure pointed to by tm shall be set to 1. Otherwise, if this name matches the name pointed to by tzname[0] then the tm_isdst member of the tm structure pointed to by tm shall be set to 0. The tm_zone and tm_gmtoff members of the structure may also be set in an unspecified manner. Members other than tm_isdst, tm_zone, and tm_gmtoff may be affected if an <tt>s</tt> conversion is also performed but shall otherwise not be affected.


On page 2149 line 70311 section strptime(), change:
If a match is found, values for the appropriate tm structure members are set to values corresponding to the locale information.

to:
If a match is found, values for the affected tm structure members are set as specified in the description of the conversion specification.


After page 2150 line 70349 section strptime() (APPLICATION USAGE), add:
The effect of the <tt>s</tt> conversion is unspecified because existing implementations differ in behavior. Some do a conversion equivalent to gmtime(), ignoring all available timezone information; some do a conversion equivalent to localtime(), using the same timezone it would use and ignoring any timezone information provided by a <tt>z</tt> or <tt>Z</tt> conversion. Although none has been observed, there may be existing (or future) implementations that use timezone information provided by a <tt>z</tt> or <tt>Z</tt> conversion, although using the latter would not be reliable as timezone names are often ambiguous. Applications that need to convert a seconds since the Epoch value to a tm structure should call gmtime() or localtime() (or their thread-safe equivalents) directly.

The effect of the <tt>z</tt> conversion is unspecified because existing implementations differ in behavior. Some just use it to set the tm_gmtoff member of the tm structure; some use the value to adjust the other field members to represent UTC, convert the resulting time to a seconds since the Epoch value, and then convert back to a tm structure by the equivalent of localtime(). An application that needs either of these behaviors should perform the necessary processing explicitly itself.

Although the <tt>Z</tt> conversion might be expected to set the tm_zone member of the tm structure, no existing implementation has been found that sets it. Applications that need it set should set it explicitly after calling strptime().

- 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
2023-07-13 09:54 geoffclare Note Added: 0006383
2023-07-13 15:17 geoffclare Note Added: 0006384
2023-07-13 15:19 geoffclare Final Accepted Text => Note: 0006384
2023-07-13 15:19 geoffclare Status New => Resolved
2023-07-13 15:19 geoffclare Resolution Open => Accepted As Marked
2023-07-13 15:19 geoffclare Tag Attached: issue8
2023-08-08 11:17 geoffclare Status Resolved => Applied
2023-08-08 11:17 geoffclare Tag Attached: applied_after_i8d3
2024-06-11 09:12 agadmin Status Applied => Closed


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