Preserve Unicode locale data in DateTime::Locale::FromCLDR

Reproduce the failures in t/01.locale.t, t/03.day_period.t, t/04.am_pm.t, t/05.timezone.t, t/06.locale_numbering_system.t, and t/10.number_system_digits.t using system Perl as the oracle. Trace the Locale::Unicode::Data/SQLite/DBI path and PerlOnJava scalar representation to find where UTF-8 bytes become Latin-1 characters. Done means a focused non-ASCII regression passes on both backends and DateTime-Locale-FromCLDR v0.8.7 passes all 219 tests.

Summary

PerlOnJava corrupts non-ASCII locale data returned by DateTime::Locale::FromCLDR v0.8.7. UTF-8 values are exposed as byte sequences interpreted as Latin-1, producing mojibake. ASCII locale data remains correct.

CPAN impact

• Distribution: DateTime-Locale-FromCLDR v0.8.7
• CPAN run: 20260913-205737-64746
• PerlOnJava result: 25 of 219 subtests failed in 6 of 15 test programs
• Affected tests: t/01.locale.t, t/03.day_period.t, t/04.am_pm.t, t/05.timezone.t, t/06.locale_numbering_system.t, and t/10.number_system_digits.t

The unaffected tests include t/07.ltr.t, t/08.dst.t, t/09.fatal.t, and the POD tests.

Observed failures

Representative values are returned as UTF-8 bytes decoded as Latin-1. For example:

got:      バチカン
expected: バチカン

Other observed mismatches include:

got:      午前
expected: 午前

got:      a. m.
expected: a. m.

got:      Ù 
expected: ٠

Failures affect Japanese, Korean, Arabic, French, and other locale data, including AM/PM names, timezone names and formats, numbering-system digits, and locale display strings.

System Perl oracle

The same distribution and dependency versions pass completely under system Perl in the archived run:

t/01.locale.t ................... ok
t/03.day_period.t ............... ok
t/04.am_pm.t .................... ok
t/05.timezone.t ................. ok
t/06.locale_numbering_system.t .. ok
t/10.number_system_digits.t ..... ok
All tests successful.
Files=15, Tests=219
Result: PASS

The distribution is pure Perl. Its Locale::Unicode::Data dependency supplies CLDR data through a bundled SQLite database; no external locale service or native prerequisite is involved in the failing path.

Expected behavior

DateTime::Locale::FromCLDR should return Perl character strings preserving the original Unicode code points and should produce the same locale names, patterns, and digit strings as system Perl.

Investigation requested

Trace the Unicode conversion boundary in the Locale::Unicode::Data/SQLite/DBI path and the PerlOnJava scalar representation. Determine where UTF-8 bytes become Latin-1 characters, then add a small system-Perl-validated regression test covering a non-ASCII CLDR value such as the Japanese AM/PM string or Arabic digits.

The issue may share infrastructure with broader Unicode byte/character problems tracked in issue #1275, but this is a distinct, reproducible CLDR data-path failure.

Acceptance criteria

• Non-ASCII CLDR values retain correct code points and UTF-8 semantics.
• The focused regression passes on JVM and interpreter backends.
• DateTime-Locale-FromCLDR v0.8.7 passes all 219 tests on both backends.