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
0000739 [1003.1(2013)/Issue7+TC1] System Interfaces Editorial Clarification Requested 2013-08-23 01:11 2021-04-15 10:05
Reporter dalias View Status public  
Assigned To
Priority normal Resolution Open  
Status New  
Name Rich Felker
Organization musl libc
User Reference
Section strftime
Page Number 2023
Line Number 64612-64623
Interp Status ---
Final Accepted Text
Summary 0000739: CX requirements for strftime seem to conflict with ISO C
Description The POSIX text for the %F format is:

"[CX] Equivalent to %+4[Option End]Y-%m-%d if no flag and no minimum field width are specified. [ tm_year, tm_mon, tm_mday]"

whereas the ISO C text is:

"%F is equivalent to ''%Y-%m-%d'' (the ISO 8601 date format). [tm_year, tm_mon, tm_mday]"

My reading of the ISO C text is that a conforming application could assume calling strftime with "%F" and with "%Y-%m-%d" produces identical output.

One could see this as a bug in the C standard, since %Y-%m-%d does not match ISO 8601, despite the above parenthetical remark.

This issue could be resolved by requiring (and indeed, I believe this is the only way an implementation can currently comply with both the POSIX and C requirements) that %Y behaves as %+4Y.
Desired Action Either add text requiring that %Y behave as %+4Y, or forward the issue to the C committee for a decision on whether C's specification of %F is erroneous.
Tags No tags attached.
Attached Files html file icon dr_strftime.html [^] (2,736 bytes) 2014-05-29 15:21

- Relationships

-  Notes
(0005315)
nick (manager)
2021-04-14 16:58

Note that the C standard does not specify the minimum field width, simply that "A conversion specifier consists of a % character, possibly followed by an E or O modifier character (described below), followed by a character that determines the behavior of the conversion specifier."

Thus it is unclear how the C standard might change for this case.
(0005318)
geoffclare (manager)
2021-04-15 10:05

Re: Note: 0005315 In order for %F to match the minimum-four-digit-year requirement of ISO 8601, the C standard could require that %F is equivalent to %Y-%m-%d except that if the year is between 0 and 999 then the %F result has leading 0's added so that the year has 4 digits. However, I don't think there is any way it can match the ISO 8601 requirements for years outside [0,9999] without adding field widths, since (quoting wikipedia) "An expanded year representation [±YYYYY] must have an agreed-upon number of extra year digits beyond the four-digit minimum", so there needs to be a way for that agreed-upon number to be used in the strftime() format string.

It appears that our requirement that %F is equivalent to %+4Y-%m-%d also does not match ISO 8601 for years between -1 and -999 because %+4Y would produce a '-' sign and 3 digits (e.g. -001) whereas ISO 8601 requires a '-' sign and four digits (e.g. -0001). We should change it to %+4Y for non-negative years and %+5Y for negative years.

- Issue History
Date Modified Username Field Change
2013-08-23 01:11 dalias New Issue
2013-08-23 01:11 dalias Name => Rich Felker
2013-08-23 01:11 dalias Organization => musl libc
2013-08-23 01:11 dalias Section => strftime
2013-08-23 01:11 dalias Page Number => unknown
2013-08-23 01:11 dalias Line Number => unknown
2013-09-05 15:52 eblake Tag Attached: c99
2013-09-05 15:53 Don Cragun Page Number unknown => 2023
2013-09-05 15:53 Don Cragun Line Number unknown => 64612-64623
2013-09-05 15:53 Don Cragun Interp Status => ---
2014-05-29 15:15 nick File Added: dr_strftime.html
2014-05-29 15:21 nick File Deleted: dr_strftime.html
2014-05-29 15:21 nick File Added: dr_strftime.html
2018-01-13 20:19 dennisw Issue Monitored: dennisw
2021-04-14 16:58 nick Note Added: 0005315
2021-04-14 16:59 nick Note Added: 0005316
2021-04-14 16:59 nick Note Deleted: 0005316
2021-04-15 10:05 geoffclare Note Added: 0005318
2021-05-17 15:10 geoffclare Tag Detached: c99


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