suggested improvements for C9x `New formats for strftime()' (N733)

You propose new conversion specifiers for strftime in C9x, the new C standard, in your document ISO/IEC JTC1/SC22/WG14 N733 <http://www.gold.net/users/cdwf/c/wg14n733.txt> (1997-07-01). Here are a couple of quotes from that document, followed by some suggestions for improvements. %f is replaced by the weekday as a decimal number (1-7), where Monday is 1 (the ISO 8601 weekday number). Please change this from %f to %u, because %u is current practice. I believe %u was introduced several years ago in Arnold Robbins's public domain strftime, and it is now the standard in many strftime implementations, including the Arthur David Olson public domain strftime <ftp://elsie.nci.nih.gov/pub/>, the GNU C library <ftp://prep.ai.mit.edu/pub/gnu/>, 4.4BSD (e.g. BSD/OS), Linux, and Solaris. %u is also required by POSIX.2's `date' command to have the same meaning (please see IEEE Std 1003.2-1992 section 4.15.4.1 page 241 line 2931); it would be odd for C9x to diverge unnecessarily from POSIX in this respect. %V is replaced by the ISO 8601 week number of the year %V does not suffice to support ISO 8601 week-oriented dates, because the ISO 8601 week's year may not be the same as the current year. For example, using ISO 8601 week notation, `1997-W01-2' denotes 1996-12-31 (as the first ISO week of 1997 begins on 1996-12-30). Similarly, `1998-W53-5' denotes 1999-01-01. If only %V is available, there's no easy way for a C program to output ISO-format dates like `1997-W01-2'. To work around this shortcoming, I propose that C9x add Robbins's %G and %g formats, as follows: %G is replaced by the year containing the ISO 8601 week %g is replaced by %G modulo 100 E.g. the format "%G-W%V-%u" outputs the ISO 8601 full week-oriented date, and the format "%gW%V%u" outputs the ISO 8601 format containing the week-oriented date without century or punctuation. %G and %g were introduced more recently by Robbins, and they are also current practice, though not as widespread as %u: they are supported by the Robbins and Olson public-domain implementations, the GNU C library, and Linux.

Paul Eggert wrote:
You propose new conversion specifiers for strftime in C9x, the new C standard, in your document ISO/IEC JTC1/SC22/WG14 N733 <http://www.gold.net/users/cdwf/c/wg14n733.txt> (1997-07-01).
I noticed another doc, N735, about wider changes in the library. <URL:http://www.gold.net/users/cdwf/c/wg14n735.txt> (1997-07-04). Item 20-25 (at the end) are relevant to the date and time functions. In particular, Item 22 is relevant to the same problem Paul quoted. In N733, Paul read
%V is replaced by the ISO 8601 week number of the year
Clive's document add that the admissible range is [00-53]. It should be put in relief that N735 adds: %#W - ISO 8601 week number ) If %W would be zero, the date is %#y - ISO 8601 week number year % 100 ) treated as belonging to week 53 %#Y - ISO 8601 week number year ) of the previous year (Note: it could be week *52* of the previous year). I read this the following way (this is nothing official): For Tuesday 1996-12-31, we should have: %y 96 %U 52 %W 52 %V 53 %#W 01 the correct ISO 8601 week %#y 97 the correct ISO 8601 year associated with the week number For Friday 1999-01-01, we should have: %y 99 %U 00 %W 00 %V 00 %#W 53 the correct ISO 8601 week %#y 98 the correct ISO 8601 year associated with the week number For Sunday 1999-01-03, we should have: %y 99 %U 01 %W 00 %V 00 %#W 53 still in the previous year %#y 98 For the fun, I add Saturday 2000-01-01: %y 00 but still in the 20th century ! %U 00 %W 00 %V 00 %#W 53 %#y 99
To work around this shortcoming, I propose that C9x add Robbins's %G and %g formats, as follows:
%G is replaced by the year containing the ISO 8601 week %g is replaced by %G modulo 100
So %G is the same as %#Y, and %g the same as %#y. But as I showed before, there is a difference between %V, showing the week number _in_the_year_ based on Monday, the first Thrusday being in week 01 (and thus able to be 00), and the real ISO 8601 week number, %#W (restricted in range to 01-53). So we probably need two specifiers, instead of one in current art. I remember a discussion some time ago in the tz list about this: in particular, some point as strange to have a week number like 53 at the beginning of the year, or a low number at the end... Antoine

Date: Mon, 07 Jul 1997 11:12:06 +0200 From: Antoine Leca <Antoine.Leca@renault.fr> There is a difference between %V, showing the week number _in_the_year_ based on Monday, the first Thrusday being in week 01 (and thus able to be 00), and the real ISO 8601 week number, %#W (restricted in range to 01-53). There is certainly a difference in the two concepts that you describe, but %V is supposed to be the ISO 8601 week number. The ISO 8601 week number can never be zero, so it must be a typo when ISO/IEC JTC1/SC22/WG14 N733 says that %V can be 00. As far as I can tell, the correspondence is as follows: common N733 N735 POSIX.2 usage meaning %f %#w %u %u ISO 8601 weekday number %V %#W %V %V ISO 8601 week number %#Y %G ISO 8601 week number year %#y %g ISO 8601 week number year modulo 100 %#Z %z timezone using RFC-822 numeric notation I don't know why the C9X draft diverges so far from common usage (not to mention POSIX.2), but at least N735 provides the needed functionality. So we probably need two specifiers, instead of one in current art. I don't see the need for a week number that is like ISO 8601's but is sometimes zero.
participants (2)
-
Antoine Leca
-
Paul Eggert