This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [v4] Fix strptime era handling, add more era tests [BZ #24394]
- From: Rafal Luzynski <digitalfreak at lingonborough dot com>
- To: TAMUKI Shoichi <tamuki at linet dot gr dot jp>, DJ Delorie <dj at redhat dot com>
- Cc: Carlos O'Donell <codonell at redhat dot com>, libc-alpha at sourceware dot org
- Date: Fri, 29 Mar 2019 12:13:49 +0100 (CET)
- Subject: Re: [v4] Fix strptime era handling, add more era tests [BZ #24394]
- References: <xnbm1upd30.fsf@greed.delorie.com> <201903290650.AA04304@tamuki.linet.gr.jp>
29.03.2019 07:50 TAMUKI Shoichi <tamuki@linet.gr.jp> wrote:
> [...]
> From: DJ Delorie <dj@redhat.com>
> Subject: [v4] Fix strptime era handling, add more era tests [BZ #24394]
> Date: Thu, 28 Mar 2019 23:35:31 -0400
>
> > diff --git a/ChangeLog b/ChangeLog
> > index bd76c1e28d..db33d8a6a3 100644
> > --- a/ChangeLog
> > +++ b/ChangeLog
> > @@ -1,3 +1,10 @@
> > +2019-03-28 DJ Delorie <dj@redhat.com>
> > +
> > + [BZ #24394]
> > + * time/strptime_l.c (%Ey): Fix fencepost error.
> > + * time/tst-strftime3.c: New.
> > + * time/Makefile (tests): Add tst-strftime3.
>
> This test case is intended to check whether strptime can correctly
> parse %EY, so it would be nice to rename it to tst-strptime4.c.
This is exactly what I was going to say. Thank you for raising
it in public first.
> [...] Regarding *_TW, Rafal-san
> is preparing a patch.
That's true. As always, my free time is limited so if anybody finds
my work too slow and wants to take the task I'm always open to this.
> In addition to ja_JP locale, I think it is necessary to check the
> locale of other countries, in particular *_TW locale.
This sounds good but also we can add other locales later.
> What about the consideration of %EY, %_EY, and %-EY?
As far as I know these flags should be ignored and all potential
input strings (no matter if they are zero-padded, space-padded
or no padded at all) should be accepted by any of these format
specifiers. At least that was the rule when I was adding a support
of "%OB"/"%Ob"/"%Oh": all format specifiers should accept all
potentially possible forms of a month name.
Of course, we may add tests to verify if these flags are correctly
ignored and all potential valid inputs are parsed correctly but
I don't have a strong desire to implement this.
> How does it behave if specifying a non-existent date, such as:
>
> Heisei gan nen 01 gatsu 07 nichi
> Showa 64 nen 01 gatsu 08 nichi
>
> I think that these tests are also necessary.
I think we can't implement this without your help.
Thank you for your feedback, best regards,
Rafal