chronos v0.1.8

chronos 0.1.8

Keep the milliseconds in toISO(), as Luxon does

chronos serialised the compact form, 2026-07-15T10:00:00Z, where Luxon's
toISO() — and therefore a serialized model under @adonisjs/lucid — returns
2026-07-15T10:00:00.000Z. Same instant, different literal, and a silent
difference in every JSON payload carrying a date. The compact form is Luxon's
opt-in toISO({ suppressMilliseconds: true }).

It was produced in TWO places that each justified themselves by matching the
other: normalizeIso() in TypeScript, and the Rust engine's canonical formatter,
which switched to SecondsFormat::Secs whenever the subsecond part was zero. So
an rrule expansion (which runs in Rust) disagreed with DateTime.toISO() on the
same instant — one value, two literals, across the NAPI boundary. Both now emit
milliseconds unconditionally.

format() is untouched: a caller-chosen token string like
YYYY-MM-DD[T]HH:mm:ss[Z] carries no milliseconds by construction, and the
canonical ISO form is toISO(), not a format string.

378b5fc

chronos: one boundary implementation for both the UTC and the zoned path

startOf/endOf had TWO implementations — Rust for UTC, a hand-written TypeScript
switch for zoned — and they had drifted. Adding startOf('second') to Rust left
the zoned switch silently returning the value unchanged for that unit, so the
same call answered differently depending on the user's zone.

• extract start_of_naive / next_unit_naive as the single core in Rust, kept side
  by side so their unit lists cannot separate
• expose start_of_in_zone / end_of_in_zone through NAPI and WASM; DateTime now
  only picks the path. No calendar arithmetic left in TypeScript
• month and year arithmetic preserve sub-second precision: both paths rebuilt
  the instant from Y/M/D + h:m:s, so plus(1, 'month') silently rounded away the
  milliseconds
• add the missing startOf/endOf('second'), which Luxon has

Tests compare both paths unit by unit, so a unit added to one only now fails.

16d07d4

---

Changes since v0.1.7.