Re: lib/55436: strptime does not process %G or %V

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR lib/55436; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: lib/55436: strptime does not process %G or %V
Date: Wed, 01 Jul 2020 12:37:23 +0700

     Date:        Tue, 30 Jun 2020 19:45:00 +0000 (UTC)
     From:        jklowden%schemamania.org@localhost
     Message-ID:  <20200630194500.7AF2E1A9228%mollari.NetBSD.org@localhost>
 
   | 	strptime(3) claims to honor %G and %V for ISO dates.
 
 Note that even though strptime(3) says that both %G and %V are NetBSD
 extensions, they are going to be in the next POSIX standard.
 
 About %G POSIX will say ..,.
 
   G    The week-based year (see below) as a decimal number (for example, 1977).
        Leading zeros shall be permitted but shall not be required. A leading
        '+' or '-' character shall be permitted before any leading zeros but
        shall not be required. The effect of this year, if any, on the tm
        structure pointed to by tm is unspecified.
 
 Note the final sentence.
 
 About %V POSIX will say ....
 
   V    The week number of the week-based year (see below) as a decimal number
        [01,53].
        Leading zeros shall be permitted but shall not be required. The effect
        of this week number, if any, on the tm structure pointed to by tm is
        unspecified.
 
 Same (or similar) final sentence.
 
 The same caveat applies to %g and %z (both also new) and has been added to
 the specifications of %U and %W.   It also appears in a modified form in the
 newly added %Z (different form, as that is required to set tm_isdst in a
 defined way, but any other effects are unspecified).
 
 The point of all of these is not so much that they can be used to parse
 a time string and extract info from them, but so the output from strftime
 can be read, without error, by a suitably constructed strptime specification.
 
 
   | It is perhaps interesting that the GNU strptime exhibits similar behavior. 
 
 Not so much really.
 
 I don't think there is any bug here.
 
 kre