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 2023-05-16 10:42
Reporter dalias View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Applied  
Name Rich Felker
Organization musl libc
User Reference
Section strftime
Page Number 2023
Line Number 64612-64623
Interp Status ---
Final Accepted Text Note: 0006141
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 applied_after_i8d3, tc3-2008
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.
(0006140)
geoffclare (manager)
2023-01-26 15:14
edited on: 2023-01-26 16:16

In the January 2023 ballot resolution meeting, WG14 decided not to make any change to functionality in C23 and will just correct the parenthetical note about ISO 8601. This means we need to remove the +4 from the format.

Change:
Equivalent to %[CX]+4[/CX]Y-%m-%d if no flag and no minimum field width are specified.
to:
Equivalent to %Y-%m-%d if no flag and no minimum field width are specified. (For years between 1000 and 9999 inclusive this provides the ISO 8601:2004 complete representation, extended format date representation of a specific day.)


On 2018 edition page 2049 line 65725 section strftime() APPLICATION USAGE, change:
For years in the range [0001,9999], POSIX.1-2017 requires that the output produced match the ISO 8601:2004 standard complete representation extended format (YYYY-MM-DD) and for years outside of this range produce output that matches the ISO 8601:2004 standard expanded representation extended format (<+/-><Underline>Y</Underline>YYYY-MM-DD).
to:
For years in the range [1000,9999], POSIX.1-2017 requires that the output produced match the ISO 8601:2004 standard complete representation extended format (YYYY-MM-DD) and for years greater than 9999 produce output that matches the ISO 8601:2004 standard expanded representation extended format (<+/-><Underline>Y</Underline>YYYY-MM-DD). For years less than 1000, %F does not produce an ISO 8601:2004 format when used without specifying at least a minimum field width.


(0006141)
geoffclare (manager)
2023-01-26 17:18

Change:
Equivalent to %[CX]+4[/CX]Y-%m-%d if no flag and no minimum field width are specified.
to:
Equivalent to %Y-%m-%d if no flag and no minimum field width are specified. (For years between 1000 and 9999 inclusive this provides the ISO 8601:2004 complete representation, extended format date representation of a specific day.)

On 2018 edition page 2049 line 65723 section strftime() APPLICATION USAGE, after:
These two forms can be produced with the '0' flag and a minimum field width options using the conversions specifications %04Y and %01Y, respectively.
add:
Similarly, because %Y is part of %F, field widths of 10 and 7 (%010F, %07F), respectively, produce the same effect in the year portion of the %F conversion result.

On 2018 edition page 2049 line 65725 section strftime() APPLICATION USAGE, change:
For years in the range [0001,9999], POSIX.1-2017 requires that the output produced match the ISO 8601:2004 standard complete representation extended format (YYYY-MM-DD) and for years outside of this range produce output that matches the ISO 8601:2004 standard expanded representation extended format (<+/-><Underline>Y</Underline>YYYY-MM-DD).
to:
For years in the range [1000,9999], POSIX.1-2017 requires that the output produced match the ISO 8601:2004 standard complete representation extended format (YYYY-MM-DD) and for years greater than 9999 produce output that matches the ISO 8601:2004 standard expanded representation extended format (<+/-><Underline>Y</Underline>YYYY-MM-DD). For years less than 1000, %F is not required to produce an ISO 8601:2004 format when used without specifying at least a minimum field width. As stated above, some implementations pad %Y conversions with zeros to four digits, in which case %F produces an ISO 8601:2004 format; other implementations do not pad %Y with zeros, in which case %F does not produce an ISO 8601:2004 format .

- 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
2023-01-26 15:14 geoffclare Note Added: 0006140
2023-01-26 15:26 geoffclare Note Edited: 0006140
2023-01-26 15:31 geoffclare Note Edited: 0006140
2023-01-26 16:16 geoffclare Note Edited: 0006140
2023-01-26 17:18 geoffclare Note Added: 0006141
2023-01-26 17:20 geoffclare Final Accepted Text => Note: 0006141
2023-01-26 17:20 geoffclare Status New => Resolved
2023-01-26 17:20 geoffclare Resolution Open => Accepted As Marked
2023-01-26 17:21 geoffclare Tag Attached: tc3-2008
2023-05-16 10:42 geoffclare Status Resolved => Applied
2023-05-16 10:42 geoffclare Tag Attached: applied_after_i8d3


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