View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000170 | 1003.1(2008)/Issue 7 | System Interfaces | public | 2009-10-15 17:51 | 2009-11-05 16:56 |
| Reporter | nick | Assigned To | ajosey | ||
| Priority | normal | Severity | Objection | Type | Error |
| Status | Resolved | Resolution | Rejected | ||
| Name | Nick Stoughton | ||||
| Organization | USENIX | ||||
| User Reference | WaynePollock:austin-group-l:archive/latest/12923 | ||||
| Section | strftime | ||||
| Page Number | 2009 | ||||
| Line Number | 63589 | ||||
| Interp Status | --- | ||||
| Final Accepted Text | |||||
| Summary | 0000170: Mis-alignment between date utility and strftime %j, and conversion specifier and tm_yday of struct tm | ||||
| Description | From Wayne Pollock's email, austin group sequence 12923: I know the aardvark has been closed on aligning the date utility with strftime (and strptime), but I just noticed that there is disagreement between these and struct tm for tm_yday. tm_yday is defined in time.h as: int tm_yday Day of year [0,365]. and %j in strftime (and strptime) is defined as: j Replaced by the day of the year as a decimal number [001,366]. [ tm_yday] Currently the date utility agrees with strftime: %j Day of the year as a decimal number [001,366]. I don't know if this "off by one" was on purpose or not. I think it is too late to change this; as far as i know strftime et. al. are implemented according to the standard, and simply don't agree with tm_yday. I would suggest that if strftime and friends isn't to be changed to agree with tm_yday, then the description for %j should be changed in all places, from: [tm_yday] to: [tm_yday + 1] -- Wayne Pollock | ||||
| Desired Action | On page 2009 line 63589, change [tm_yday] to [tm_yday+1] | ||||
| Tags | c99 | ||||
|
|
I think the proposed change is wrong. The standard is clear that the entire list of strftime conversion specifiers uses "zero or more members of the broken-down time structure pointed to by timeptr, as specified in brackets in the description" (line 63534), so it is an indication of _which_ members are used to compute the resulting string, and not _how_ those members are used in performing the calculation. The correct calculation for %j needs to be a string representation of the decimal value of tm_yday+1 with leading zeros, but that is already implied by the difference in ranges for what tm_yday can contain [0-365] and what %j will produce [001-366]. Meanwhile, the spec is correct as is in stating that %j relies on the value of the tm_yday. If we were to change brackets after %j to list a formula, then we would have to consider changing all the other conversion specifiers to also give formulas; and it gets complex fast (for example, what is a succinct formula for %V, which is shown on line 63609 as depending on the tm_year, tm_wday, and tm_yday fields?). |
|
|
The suggested change would create a conflict with the C Standard. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2009-10-15 17:51 | nick | New Issue | |
| 2009-10-15 17:51 | nick | Status | New => Under Review |
| 2009-10-15 17:51 | nick | Assigned To | => ajosey |
| 2009-10-15 17:51 | nick | Name | => Nick Stoughton |
| 2009-10-15 17:51 | nick | Organization | => USENIX |
| 2009-10-15 17:51 | nick | User Reference | => WaynePollock:austin-group-l:archive/latest/12923 |
| 2009-10-15 17:51 | nick | Section | => strftime |
| 2009-10-15 17:51 | nick | Page Number | => 2009 |
| 2009-10-15 17:51 | nick | Line Number | => 63589 |
| 2009-10-15 17:51 | nick | Interp Status | => --- |
| 2009-10-15 19:30 | eblake | Note Added: 0000260 | |
| 2009-10-15 19:32 | eblake | Note Edited: 0000260 | |
| 2009-10-16 08:26 | geoffclare | Note Added: 0000261 | |
| 2009-11-05 16:53 | nick | Tag Attached: c99 | |
| 2009-11-05 16:56 | nick | Status | Under Review => Resolved |
| 2009-11-05 16:56 | nick | Resolution | Open => Rejected |
