[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: lib/55436: strptime does not process %G or %V
The following reply was made to PR lib/55436; it has been noted by GNATS.
From: Robert Elz <kre%munnari.OZ.AU@localhost>
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)
| 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
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
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.
Main Index |
Thread Index |