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

[David Holland <dholland-bugs%netbsd.org@localhost>]

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

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: lib/55436: strptime does not process %G or %V
Date: Wed, 9 Jun 2021 04:43:50 +0000

 not sent to gnats
 
    ------
 
 From: Brian Ginsbach <ginsbach%netbsd.org@localhost>
 To: "James K. Lowden" <jklowden%schemamania.org@localhost>
 Cc: lib-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
 Subject: Re: lib/55436: strptime does not process %G or %V
 Date: Thu, 2 Jul 2020 18:23:43 +0000
 
 On Wed, Jul 01, 2020 at 11:00:02PM +0000, James K. Lowden wrote:
 > The following reply was made to PR lib/55436; it has been noted by GNATS.
 > 
 > From: "James K. Lowden" <jklowden%schemamania.org@localhost>
 > To: gnats-bugs%netbsd.org@localhost
 > Cc: 
 > Subject: Re: lib/55436: strptime does not process %G or %V
 > Date: Wed, 1 Jul 2020 18:57:41 -0400
 > 
 >  On Wed,  1 Jul 2020 05:40:02 +0000 (UTC)
 >  Robert Elz <kre%munnari.OZ.AU@localhost> wrote:
 >  
 >  >  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. 
 >  
 >  Thank you very much for the explanation.  I'm astonshed by POSIX's
 >  rationale.  I don't see how skipping over metacharacter sequences
 >  without parsing them into the output helps anyone.  It's a recipe for
 >  error.  
 
 This is a very good explaination by kre. Again, originally strptime(3)
 was not a 1-to-1 match for strftime(3) regarding format specifiers.
 True not parsing can be a recipe for error but so can parsing
 without enough data.
 
 >  
 >  I note that on my system, no mention is made on the man page for
 >  strptime that %G and %V are accepted but inoperative.  
 >  
 >  I just spent two days working around this ... feature.  Would NetBSD be
 >  interested in a patch that makes the unspecified result useful?  
 
 I have worked on NetBSD's strptime(3) off and on over the years.
 The last time I surveyed OSS implementations of strptime(3) there
 were no implementations that did anything useful with either %G or
 %V. Hence, in part, why NetBSD's and the GNU C library's strptime(3)
 behave similarly for these two.
 
 However, I do have local changes that will help make %G and %V
 useful in some cases.  Just haven't had the time to commit the
 code. NetBSD 9.0 has a lot of changes to strptime(3), including a
 framework that makes it easier to, under the right circumstances,
 handle %G and %V, rather than simply skipping them.
 
 Unfortunately, as the kre pointed out in the POSIX text there are
 cases where it is not possible to fill in a struct tm. Your test
 case is a perfect example. What year should be used when the only
 data parsed is W26 into W%V?  Current year? Last year? Here is a
 comment from my uncommitted code that illustrates some of these
 issues:
 
 
 	/*
 	 * N.B. mixing ISO and non-ISO conversion
 	 * specifiers is undefined.  We convert:
 	 *  %U with %[Gg] same as %U with %[Yy]
 	 *  %V with %[Yy] same as %V with %[Gg]
 	 *  %W with %[Gg] same as %V with %[Gg] (week > 0)
 	 *  %W with %[Gg] same as %W with %[Yy] (week == 0)
 	 */
 
 If you have changes against the latest NetBSD version of strptime(3)
 please send them along. I will see how they compare with my
 uncommitted changes.
 
 Brian