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

[DJ Delorie <dj at redhat dot com>]

"Carlos O'Donell" <codonell@redhat.com> writes:
>> +  { "Japanese era change, 1926, before first transition's year",
>> +    1925, Dec,  31, Thu, 12, 00, 00, "ja_JP.UTF-8", "%EY",
>> +    "\345\244\247\346\255\24314\345\271\264", 1 },
>
> I'm not happy to see explicitly written out binary mbcs data here.
>
> However, if we don't do this then we can't support multiple encodings
> in one test file because the editor might display the data oddly or
> even write out the wrong thing.

Yeah, we really want to be independent of other converters.  Each test
case should, ideally, be independently vetted by a native speaker.  The
data in the test case should be in whatever format allows for a
guaranteed result while being maintainable.

This type of data has to be a compromise, between "easy to maintain" and
"guaranteed accurate".  I prefer to err to accuracy.

> (a) Explicit code points.
>
> I would like to see something like this:
>
> "<U5E73><U6210>3<U5E74>"
>
> Which is then converted by the test framework into the output encoding.

Complexity makes the test harder to understand overall, and adds
dependencies on other tools getting the conversion correct.

> * Use wcsrtombs to convert (according to current locale).

This uses the same code as strftime would use.  If there are bugs in
that code, they'd go undetected.

Now, if you want to put both wide and narrow char strings in the test,
and validate them, fine... but that's a wcsrtombs test, not a strftime
test.

> (b) Explain how to convert back and forth.

This is the weak but easy part.  I put in a NULL string and let the test
print out what should have been there :-)

Our test framework prints mismatched strings as either \oct\strings or
HE XS TR IN GS.  The first is more convenient for cutting and pasting
into the test, so I did.

Conveniently, the test *also* prints the strings in its stdout, so if
your terminal has the right encoding, you can see the string "as is"
when you run the test.  Yes, you have to run the test multiple times,
with your terminal set for each encoding, to check them all.

I can document all this.  I can also replace the TEST_COMPARE_STRING
with a custom function that prints the string in a more suitable format
for reviewing and cut-n-paste-ing, but I wanted to keep the framework
simple and "standard" for now.

>> +  { "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.

>> +      /* 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?

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."