Time::Format 1.16 exposes import and locale compatibility failures #1635

Summary

The upstream Time::Format 1.16 suite passes under system Perl but fails under PerlOnJava on both execution backends. The archived run shows two independent compatibility failures: custom imports do not make exported symbols available under strict, and localized month/day names remain English after changing LC_TIME.

Evidence

CPAN run 20261005-091352-31215:

• System Perl 5.42.2: isolated install of the exact distribution and prerequisites, including recommended Date::Manip 7.00; all 26 test programs / 533 tests passed.
• PerlOnJava JVM backend: 6/515 subtests failed across 4/26 test programs.
• PerlOnJava interpreter backend: reproduced failures in t/export1.t, t/export2.t, t/export3.t, and t/locale.t.
• Environment: macOS arm64, Java 24.0.2. The archived PerlOnJava log reports Perl 5.044001; the exact source commit was not recorded.

Failure 1: custom exports and strict compilation

The export tests load Time::Format with use_ok, which succeeds, then abort because imported %strftime, %manip, or %time symbols are still reported as undeclared. t/export2.t also reports Time::Format as a bareword under strict subs. The module's custom import installs aliases through symbolic typeglob assignments. PerlOnJava should make those imported symbols visible to the caller's strict compilation, as system Perl does.

Failure 2: locale changes are not reflected by I18N::Langinfo

t/locale.t fails the six French, German, and Spanish month/day checks; the returned names stay English. A focused probe shows POSIX::setlocale(LC_TIME, ...) returns the requested locale on PerlOnJava, but I18N::Langinfo::langinfo(MON_6()) still returns June on both JVM and interpreter. System Perl returns localized month names after the same calls.

Expected

All upstream tests should pass on both PerlOnJava backends. The imported-symbol behavior and the POSIX::setlocale/I18N::Langinfo interaction can be handled independently if they have different owners.