Sorry about that. Let's try again with the correct subject line... Begin forwarded message:
> From: Don Cragun <dcragun at sonic.net> > Date: December 16, 2009 1:08:38 AM PST > To: Ienup.Sung at Sun.COM > Cc: PSARC-ext at Sun.COM, i18n-discuss at opensolaris.org > Subject: Re: opensolaris-arc Digest, Vol 46, Issue 49 > > On Dec 15, 2009, at 5:36 PM, Ienup Sung wrote: > >> Don Cragun wrote at 12/15/09 17:08: >>> Hi Ienup, >>> I support the changes in functionality provided by this case. >>> However, I have a few minor quibbles with the references to ISO 8601 >>> in the provided man page updates: >>> 1. A revision to ISO 8601 was adopted in 2004, so ISO 8601:2000 is >>> obsolete. >>> 2. ISO 8601 specifies dozens of "standard date formats" so saying that >>> %F uses "the ISO 8601:2000 standard date format" is misleading. >>> 3. It is strange that %F specifies an ISO 8601 Extended format (with '-' >>> separators between fields) and a %z using Basic format (without a ':' >>> separator). ISO 8601 explicitly disallows any date and time >>> representation where basic and extended formats are mixed; all date, >>> time, and offset fields must be in basic format, or all of the >>> fields must be in extended format. >>> From getdate(3c): >>> %F Equivalent to %Y-%m-%d (the ISO 8601:2000 standard date >>> | >>> format). >>> | >>> should be: >>> %F Equivalent to %Y-%m-%d (the ISO 8601:2004 standard date >>> | >>> in extended format). >>> | >>> and: >>> %z Offset from UTC in ISO 8601:2000 standard format (+hhmm >>> | >>> or -hhmm), or no characters if no time zone is determinable. >>> | >>> should be: >>> %z Offset from UTC in ISO 8601:2004 standard basic format (+hhmm >>> | >>> or -hhmm), or no characters if no time zone is determinable. >>> | >>> The same changes are needed to the %F and %z descriptions in strftime(3c) >>> and strptime(3c). >>> Cheers, >>> Don >> >> Hello Don, >> >> Thanks very much for your comment. I updated as you pointed out and >> placed the updated man pages and diff files at the materials directory of >> the case. >> >> In the previous man pages from me, I didn't update them in this regard >> since XSH6 specs/man pages also appear still referencing ISO 8601:2000 >> and in the manner shown in the current man pages (of before this project). >> >> Ienup >> > > The description of the F conversion specifier in XSH7 is: > "CX F Equivalent to %+4Y-%m-%d if no flag and no minimum field width > are specified. [tm_year, tm_mon, tm_mday] > > "CX If a minimum field width of x is specified, the year shall be > output as if by the Y specifier (described below) with whatever > flag was given and a minimum field width of x?6. If x is less > than 6, the behavior shall be as if x equalled 6. > > "CX If the minimum field width is specified to be 10, and the year > is four digits long, then the output string produced will match > the ISO 8601:2004 standard subclause 4.1.2.2 complete > representation, extended format date representation of a > specific day. If a + flag is specified, a minimum field width > of x is specified, and x?7 bytes are sufficient to hold the > digits of the year (not including any needed sign character), > then the output will match the ISO 8601: 2004 standard > subclause 4.1.2.4 complete representation, expanded format > date representation of a specific day." > > I was working on the plans for providing SUSv4 conformance to Solaris > next when I was RIFed. Obviously, these functions all need to be > updated if Sun or Oracle intend to get the next UNIX brand for an > upcoming Solaris release. > > - Don
