NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



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


Home | Main Index | Thread Index | Old Index