|Anonymous | Login||2023-06-10 17:07 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details [ Jump to Notes ]||[ Issue History ] [ Print ]|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0000170||[1003.1(2008)/Issue 7] System Interfaces||Objection||Error||2009-10-15 17:51||2009-11-05 16:56|
|Final Accepted Text|
|Summary||0000170: Mis-alignment between date utility and strftime %j, and conversion specifier and tm_yday of struct tm|
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:
Replaced by the day of the year as a decimal number [001,366]. [ tm_yday]
Currently the date utility agrees with strftime:
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,
[tm_yday + 1]
On page 2009 line 63589, change
edited on: 2009-10-15 19:32
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.|
|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|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|