Files
Dylan M. Taylor e3169e5a61 collab/ui-egui: keep old UTC output past chrono's year range
`utc_date` (collab) and `date` (ui-egui) took `u64` seconds, which the old
hand-rolled civil-from-days code converted for the whole `u64` range. The
chrono rewrite used `from_timestamp(..).unwrap_or_default()`, so any instant
past chrono's own year limit (262143) silently became the epoch — changing
existing output. `u64::MAX` seconds, for example, used to read
`584554051223-11-09 07:00 UTC` / `Nov 9, 584554051223`, not 1970.

Fix: add a `utc_parts(days, sod, nanos)` helper per crate that moves the
instant into chrono's range by whole 400-year Gregorian cycles (146_097 days),
lets chrono do the month/day/time, and restores the real year afterwards.
chrono stays the only calendar logic; the cycle count just shifts the year, and
every `u64` day count fits in `i64` so the conversion is always exact (no epoch
fallback). Split seconds with `u64` arithmetic first to avoid the `i64` seconds
overflow near `u64::MAX`, matching the old code.

Tests now pin the old output instead of the epoch:
- collab utc_date(u64::MAX) == "584554051223-11-09 07:00 UTC"
  (and utc_date(253_402_300_800) == "10000-01-01 00:00 UTC", already pinned)
- ui-egui date(253_402_300_800) == "Jan 1, 10000"
  date(u64::MAX) == "Nov 9, 584554051223"
2026-10-22 07:12:29 -04:00
..
2026-10-11 16:21:16 +07:00
2026-10-20 01:43:53 +07:00
2026-10-11 16:21:16 +07:00
2026-10-10 23:53:05 +07:00
2026-10-16 01:35:37 +07:00
2026-10-20 01:43:40 +07:00
2026-10-12 17:54:18 +07:00
2026-10-20 01:34:10 +07:00
2026-10-20 04:39:04 +07:00
2026-10-16 02:03:46 +02:00
2026-10-11 16:21:16 +07:00
2026-10-20 01:13:35 +07:00
2026-10-20 05:58:56 +07:00
2026-10-17 20:48:35 +07:00