mirror of
https://github.com/storytold/cadcraft.git
synced 2026-10-24 10:56:51 -06:00
Dylan M. Taylor
acd109d97c
* Use chrono for UTC/calendar conversion instead of hand-rolled copies Replaces the three civil_from_days copies (logging timestamp, Drawing Recovery time, parity checklist date) with chrono as a workspace dependency. Output formats are unchanged and pinned by the existing tests. AGENTS.md now says time goes through chrono. Fixes #1785 * Never panic on a clock outside chrono's range; keep 5-digit years unprefixed chrono's From<SystemTime> unwraps, so a clock past year 262143 panicked inside the logger. timestamp and xtask's date now use the fallible DateTime::from_timestamp and read such a clock as the epoch, as the old saturating code did. xtask's date also clamps a pre-epoch clock to 1970-01-01 again. Years past 9999 are written with {:04} like before, because %Y would add a '+'. Tests cover all three cases. * Don't build an unrepresentable SystemTime in the far-future test UNIX_EPOCH + Duration::from_secs(u64::MAX / 2) overflows Windows' SystemTime and panicked before timestamp() ran, failing the Windows test job. Build it with checked_add and only assert where it exists. * logging/autosave/parity: keep extended-year dates, no epoch fallback Applies the stricter no-epoch-fallback rule (from wordcraft#3427 / filmcraft#2662, superseding the earlier epoch-or-last-valid suggestion) so all sibling PRs agree: a timestamp the old code converted past chrono's year 262143 range must keep its real proleptic-Gregorian date, not collapse to 1970-01-01. Each site uses the 400-year Gregorian cycle (146_097 days) with chrono as the only calendar logic: chrono converts the day within one cycle, whole cycles carry in the year (i128, saturated into i64). This also removes the panic FredApps flagged — `DateTime::<Utc>::from(SystemTime)` could panic past chrono's range; `from_num_days_from_ce_opt` within one cycle never does. Verified the cycle result equals the old formula across a wide range and at the extremes. - apps/cadcraft/src/logging.rs `timestamp`: cycle `civil_from_days(u64)`; pre-1970 epoch clamp and ms/time-of-day format kept. Pins: +10_000_000_000_000 s -> 318857-05-20T17:46:40.000Z (was 1970-...); checked_add u64::MAX/2 s -> 292277026596-12-04T15:30:07.000Z (was epoch). - crates/ui-egui/src/autosave.rs `utc`: cycle converter. Pins: utc(10_000_000_000_000) = "318857-05-20 17:46"; utc(u64::MAX) = "584554051223-11-09 07:00" (was "1970-01-01 00:00"). - xtask/src/parity.rs `date`: cycle converter; pre-1970 epoch clamp kept. Pins: day(115_740_740) = "318857-05-20"; checked_add u64::MAX/2 s -> "292277026596-12-04" (was epoch). * Don't build a year-318857 SystemTime unchecked in the logging test Windows' SystemTime only reaches about year 30828, so UNIX_EPOCH + Duration::from_secs(10_000_000_000_000) panicked before timestamp() ran and failed the Windows test job. Build it with checked_add and assert where the platform can hold it. The year-10000 case fits everywhere and stays unconditional. * Name the 400-year range extension as the one exception to the time rule The rule said never to hand-roll calendar math, but the range fix (shifting by whole 400-year Gregorian cycles so dates past chrono's year range keep their old output) is cycle arithmetic, so the rule and the code disagreed. The rule now names that exception: the library still computes month, day and time, and only whole cycles are carried in the year. * Say the library computes month and day; time-of-day is plain arithmetic Narrows the range-extension wording: the date library computes the calendar fields, and splitting seconds into hours, minutes and seconds is ordinary arithmetic, which is what the code does.