Austin Group Defect Tracker

Aardvark Mark IV

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
Reporter nick View Status public  
Assigned To ajosey
Priority normal Resolution Rejected  
Status Resolved  
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
Attached Files

- Relationships

-  Notes
(0000260)
eblake (manager)
2009-10-15 19:30
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?).
(0000261)
geoffclare (manager)
2009-10-16 08:26

 The suggested change would create a conflict with the C Standard.

- Issue History
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

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