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: TAMUKI Shoichi <tamuki at linet dot gr dot jp>
- To: Carlos O'Donell <codonell at redhat dot com>, DJ Delorie <dj at redhat dot com>
- Cc: Rafal Luzynski <digitalfreak at lingonborough dot com>, libc-alpha at sourceware dot org
- Date: Sat, 30 Mar 2019 21:51:16 +0900
- Subject: Re: [v4] Fix strptime era handling, add more era tests [BZ #24394]
- References: <ea8e0baa-637c-2823-7a1f-790aba776daa@redhat.com>
Hello Carlos-san,
From: Carlos O'Donell <codonell@redhat.com>
Subject: Re: [v4] Fix strptime era handling, add more era tests [BZ #24394]
Date: Fri, 29 Mar 2019 10:53:09 -0400
> > The test case to check whether strftime can correctly format %EY
> > already exists as tst-strftime2.c. This covers ja_JP, lo_LA, th_TH,
> > zh_TW, cmn_TW, hak_TW, nan_TW, and lzh_TW. Regarding *_TW, Rafal-san
> > is preparing a patch.
>
> The *most important* thing for me is that ja_JP get coverage of the
> possible interface uses for the upcoming era name change.
>
> I suggest we focus *only* on ja_JP locale today, and get the new test
> in place to test the April 1st new era name change.
Agreed.
> > In addition to ja_JP locale, I think it is necessary to check the
> > locale of other countries, in particular *_TW locale.
>
> Agreed. We can add these later.
>
> > What about the consideration of %EY, %_EY, and %-EY?
>
> Agreed. We can add these later.
>
> For now I think testing %EY is the single most useful thing, and I
> think we could accept the patch just for that.
Agreed.
> > 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.
>
> As Rafal points out I think we could use your help there. If we
> accept DJ's patch then you could work on top of that to add a few
> more test cases to check invalid tests?
Yes, I can contribute as needed. Since it is expected that the
response to the new era of some systems is delayed, I think that there
is a case to parse non-existent date. According to the Japanese
government, the use of "H31.5.1", "H31.8.12", etc. are permitted for a
certain period of time.
Regards,
TAMUKI Shoichi