Re: Fix strptime era handling, add more era tests [BZ #24394]

[Carlos O'Donell <codonell at redhat dot com>]

On 3/28/19 1:07 PM, DJ Delorie wrote:
> > > +  { "Japanese era change, 1926, start of first transition's year",
> > > +    1926, Jan,   1, Fri, 12, 00, 00, "ja_JP.UTF-8", "%EY",
> > > +    "\345\244\247\346\255\24315\345\271\264", 1 },
> >
> > These should be \x hex escape sequnces because they then match the output
> > from the charmap data (if you choose option (b) above), which makes it
> > easier to double check output.
>
> See above (wrt format); also, see above (wrt test printing strings).
>
> Given the "multiple encodings" problem, presenting strings-as-glyphs in
> the editor is tricky.

We don't need to use glyphs. I just want hex here to make looking these
up easier. If you convert these to \x then I think we'll be OK (not \u).

> > > +      /* Not all conversions are reversible.  */
> >
> > Why? All of them should be reversible. You fixed the bug that made them
> > not reversible?
>
> Do we guarantee that for *every* supported strftime format, in every
> locale, that strptime can parse it with the *same* format?

Yes.

> I'm willing to add a note that "if your conversion is not reversible,
> add a comment to the test case explaining why it isn't a bug."
 
The only way the conversion would be irreversible is if a transliteration
occurred that converted M symbols to N symbols, but that's not the case
here.

It should be rerversible or it's a bug.

--
Cheers,
Carlos.