Defect in XSH strftime

[Paul Eggert]

In <https://www.opengroup.org/sophocles/show_mail.tpl?source=L&listname=austin-group-l&id=7964>,
Eric Blake <ebb9 at byu.net> writes:

> this means that %Y is not equivalent to %C%y, since %C is documented
> to be exactly two digits

This topic came up around 2004-08-20 in the tz mailing list.
(Please see <http://www.twinsun.com/tz/tz-link.htm> for info about the
list; it is archived in <ftp://elsie.nci.nih.gov/pub/tzarchive.gz>.)

The consensus was as follows (presumably a defect report could also be
submitted to POSIX, as POSIX can place requirements on strftime that
are over and above what ISO C requires):

 * The ISO C standard is broken in this area; the standardizers did
   not think about the problem.  (One of those involved in the tz
   discussion was also involved with the ISO C effort.)

 * A Defect Report should be submitted.  (Nobody has yet done so, to my
   knowledge.)

 * Best practice (which is not currently required by any standard) is
   to have the following behavior, originally suggested by
   Arthur David Olson:

     - %Y always generates the mathematically-correct result,
       even if the expression "tm.tm_year + 1900" would overflow.

     - %Y is always equivalent to %C%y.

     - %y is always in the range [00,99].

     - %C is in the range [00,99] when possible.

     - %C is two characters long when possible.

    Here are some examples:

        %Y     %C   %y
       10000   100  00
       9999    99   99
       0999    09   99
       0099    00   99
       0001    00   01
       0000    00   00
       -001    -0   01
       -099    -0   99
       -999    -9   99
       -1000   -10  00
       -10000  -100 00

          %Y         %C      %y
       -2147481749 -21474817 49
       2147485547  21474855  47

    Note that the last example overflows 32-bit 'int', but it is the
    best-practice behavior even on 32-bit-int hosts.

 * The tz library <ftp://elsie.nci.nih.gov/pub/> now has the
   best-practice behavior suggested above.