DateTime::Format::Epoch microsecond output uses scientific notation

Start with the focused failure in t/004_nano.t and run the minimal arithmetic reproducer on both backends. Trace the numeric representation and stringification path exercised by the 1e6 multiplier. Done means the reproducer uses decimal notation where standard Perl does, preserves scientific notation elsewhere, and the full DateTime::Format::Epoch suite passes all 133 tests.

Summary

DateTime::Format::Epoch 0.16 fails one upstream test under PerlOnJava because a large integer-valued numeric result is stringified in scientific notation instead of decimal notation.

Reproduction

Run the normal DateTime::Format::Epoch 0.16 test suite.

The focused failing test is t/004_nano.t, which constructs a formatter with unit => "microseconds" and formats a DateTime corresponding to 1051470597800000 microseconds since the epoch.

A minimal arithmetic reproducer is:

my $x = 1051470597;
$x *= 1e6;
$x += int(0.8 * 1e6);
print "[$x]\\n";

Expected result

System Perl prints:

[1051470597800000]

The complete upstream suite passes under system Perl: 20 files and 133 tests.

Actual result

PerlOnJava prints:

[1.0514705978e+15]

The CPAN test failure is:

# Failed test '"now" (micro)'
# at t/004_nano.t line 32.
# got: '1.0514705978e+15'
# expected: '1051470597800000'

The archived compatibility run recorded 1 failed test program and 1 failed subtest out of 20 programs and 133 subtests. The focused arithmetic reproducer produces the same scientific notation on both the JVM and interpreter backends.

Likely root cause

DateTime::Format::Epoch maps microseconds to the numeric literal 1e6. With the default integer mode for this unit, Perl preserves the integer-valued result in decimal string form. PerlOnJava promotes or retains the calculation as a floating-point scalar and formats the large integer-valued result using scientific notation.

This is a shared numeric representation/stringification compatibility issue, not a CPAN distribution defect, missing prerequisite, timeout, or native-code dependency.

Acceptance criteria

• Integer-valued arithmetic such as the reproducer stringifies as decimal rather than scientific notation when Perl does so.
• DateTime::Format::Epoch 0.16 passes all 133 upstream tests on both backends.
• Add a project-owned regression test for large integer-valued arithmetic involving a 1e6 multiplier and decimal stringification.
• Preserve scientific notation for values and contexts where standard Perl actually uses it.

Evidence

• CPAN run: 20260918-141920-96054
• Distribution: DateTime-Format-Epoch-0.16
• Failing test: t/004_nano.t, test 8 ("now" (micro))
• System Perl: PASS, 20 files / 133 tests
• PerlOnJava: FAIL, 1 file / 1 subtest
• JVM and interpreter: focused arithmetic reproducer confirmed

Related issue check

Issue #1283 concerns omitted optional arguments becoming explicit undef in DateTime::Format::Builder; it is related only by the DateTime ecosystem and does not cover this numeric-formatting failure. No duplicate issue was found for this distribution, test, or scientific-notation symptom.