View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
00007391003.1(2013)/Issue7+TC1System Interfacespublic2013-08-23 01:112024-06-11 09:02
Reporterdalias Assigned To 
PrioritynormalSeverityEditorialTypeClarification Requested
Status ClosedResolutionAccepted As Marked 
NameRich Felker
Organizationmusl libc
User Reference
Sectionstrftime
Page Number2023
Line Number64612-64623
Interp Status---
Final Accepted Text0000739:0006141
Summary0000739: CX requirements for strftime seem to conflict with ISO C
DescriptionThe 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 ActionEither 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.
Tagsapplied_after_i8d3, tc3-2008
Attached Files
dr_strftime.html (2,736 bytes)    
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>
<head>
  <meta name="generator" content=
  "HTML Tidy for Mac OS X (vers 31 October 2006 - Apple Inc. build 15.6), see www.w3.org">
  <meta http-equiv="Content-Type" content=
  "text/html; charset=us-ascii">

  <title>Defect report #XXX</title>
</head>

<body>
  <br>

  <h2 align="center">Defect Report #XXX</h2><a href=
  "dr_XXX.htm">Previous Defect Report</a> &lt; - &gt; <a href=
  "dr_XXX.htm">Next Defect Report</a><br>


  <p><b>Submitter:</b> Nick Stoughton (US)<br>
  <b>Submission Date:</b> 2014-05-08<br>
  <b>Source:</b> Austin Group<br>
  <b>Reference Document:</b> <a href=
  "http://austingroupbugs.net/view.php?id=739">Austin Group Bug 739</a><br>

  <b>Version:</b> 1.1<br>
  <b>Date:</b> May 2014<br>
  <b>Subject:</b> <code><b>strftime</b></code> %F equivalency
  problems and number of digits for %Y</p>

  <p><b>Summary</b></p>

  <p>The C Standard normatively requires that for the <code>strftime</code> function,
  the <code>"%F"</code> format specifier is equivalent to 
  <code>"%Y-%m-%d"</code>. There is also an informational note (in parentheses) that
  this is supposed to be the same as an ISO 8601 date. However, 8601 requires
  years to be a minimum of 4 digits. </p>
  <p>Given a year &lt; 1000, how many digits does %Y produce? The normative text states
  only <quote>"%Y is replaced by the year as a decimal number (e.g., 1997). [tm_year]"</quote>.</p>
  <p>POSIX, however, requires (as a C extension) that 
  <quote>"[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]"</quote> (note, POSIX includes an extension
  to specify field widths).</p>

 <p>If %F is indeed intended to be a means to print ISO-8601 formatted dates, then
 %Y should always produce a minimum of 4 digits.</p>
  <p><b>Suggested Change</b></p>EITHER: at 7.27.3.5 para 3, change:

  <blockquote>
  %Y is replaced by the year as a decimal number (e.g., 1997). [tm_year]
  </blockquote>to

  <blockquote>
  %Y is replaced by by at least 4 digits of the year as a decimal number (e.g., 1997). [tm_year]
  </blockquote>
  </p><p>OR: at 7.27.3.5 para 3, change:

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

  <blockquote>
  %F is equivalent to "%Y-%m-%d", except that the year shall have a minimum of 4 digits
  (the ISO 8601 date format). [tm_year, tm_mon, tm_mday]
  </blockquote>
  <hr>

  <p><b>Committee Discussion</b></p>


  <p><b>Proposed Technical Corrigendum</b></p>


  <p><a href="dr_XXX.htm">Previous Defect Report</a> &lt; - &gt;
  <a href="dr_XXX.htm">Next Defect Report</a></p>
</body>
</html>
dr_strftime.html (2,736 bytes)   

Activities

nick

2021-04-14 16:58

manager   bugnote:0005315

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.

geoffclare

2021-04-15 10:05

manager   bugnote:0005318

Re: 0000739: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.

geoffclare

2023-01-26 15:14

manager   bugnote:0006140

Last edited: 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.


geoffclare

2023-01-26 17:18

manager   bugnote:0006141

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
2021-04-14 16:58 nick Note Added: 0005315
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 => 0000739: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
2024-06-11 09:02 agadmin Status Applied => Closed