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

Tái hiện các lỗi trong t/01.locale.t, t/03.day_period.t, t/04.am_pm.t, t/05.timezone.t, t/06.locale_numbering_system.t và t/10.number_system_digits.t bằng cách sử dụng system Perl làm oracle. Theo dõi đường dẫn Locale::Unicode::Data/SQLite/DBI và biểu diễn scalar của PerlOnJava để tìm nơi các byte UTF-8 bị chuyển thành các ký tự Latin-1. Công việc được xem là hoàn tất khi một hồi quy tập trung vào ký tự không phải ASCII vượt qua trên cả hai backend và DateTime-Locale-FromCLDR v0.8.7 vượt qua tất cả 219 bài kiểm thử.

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.