View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001727 | Issue 8 drafts | System Interfaces | public | 2023-05-14 19:23 | 2024-06-11 09:12 |
| Reporter | kre | Assigned To | |||
| Priority | normal | Severity | Objection | Type | Enhancement Request |
| Status | Closed | Resolution | Accepted As Marked | ||
| 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 | 0001727: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 | ||||
|
|
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. |
|
|
> 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. |
|
|
> 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. |
|
|
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. |
| 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 | => 0001727: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 |
