Construct new Date() from clock ticks without intermediate conversions

[lahma]

What

The zero-argument new Date() path computed (GetUtcNow().DateTime - Epoch).TotalMilliseconds — a
DateTimeOffset → DateTime → TimeSpan → double chain — and then re-validated the value through
TimeClip inside the JsDate constructor. The milliseconds now come straight from ticks
((UtcTicks − EpochTicks) / TicksPerMillisecond), and a clip-free internal constructor stores them
directly: integer division truncates toward zero exactly like TimeClip for positive values, and a
ticks-derived current time is always inside the clip range. The subclass path
(OrdinaryCreateFromConstructor) keeps the spec pipeline.

Results

DateConstructionBenchmarks A/B (default job, adjacent runs):

row	before	after
NewDateNow	9.060 ms	8.048 ms	−11.2% (90.6 → 80.5 ns per new Date())
NewDateMillis (guard, untouched path)	11.66 ms	11.81 ms	flat — launchCount-5 median; a single-launch +7.6% was a process mode

Allocations byte-identical. Honest framing for stopwatch.js (which spends ~13% of its time in
new Date(), ~196k per op): the expected ~1% row gain sits inside the row's noise floor — the
±0.7% wall-clock driver read flat — so this is a micro-path win, not a row mover.

Gating

All-TFM build ✅ · Jint.Tests ×2 ✅ · PublicInterface ×2 ✅ · Test262 99,426/0 ✅

🤖 Generated with Claude Code