mirror of
https://github.com/storytold/soundcraft.git
synced 2026-10-24 10:36:46 -06:00
Dylan M. Taylor
d47abe484d
* Use chrono for UTC/calendar conversion instead of hand-rolled copies Replaces the civil_from_days copy behind the desktop app's log timestamp with chrono as a workspace dependency. The output format is unchanged and pinned by the existing test. AGENTS.md now says time goes through chrono. Follow-up to storytold/cadcraft#1785 * Never panic logging on a clock outside chrono's range chrono's From<SystemTime> unwraps internally, so a clock past year 262143 panicked inside the logger. timestamp now reads the duration since the epoch and goes through the fallible DateTime::from_timestamp, reading an out-of-range clock as the epoch, exactly as the pre-epoch clamp already did. The year is written with {:04} rather than %Y, which would prefix a '+' past year 9999. Tests cover the far-future and year-10000 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. * time: preserve old out-of-range log timestamp (no epoch fallback) `DateTime::from_timestamp(...).unwrap_or_default()` silently reset any clock past chrono's year range to 1970-01-01, changing output the old hand-rolled `civil_from_days` converted exactly. Restore the old conversion domain with a cycle-based helper that routes the calendar through chrono (the calendar repeats every 400 years = 146_097 days, so month/day/time come from chrono and only the year is carried in i128, keeping every i64 exact). Keep the pre-1970 epoch clamp; u64 seconds past i64::MAX saturate rather than falling back. Pinned old outputs in the test (replacing the u64::MAX/2 -> epoch assertion): u64::MAX/2 s -> 292277026596-12-04T15:30:07.000Z 10_000_000_000_000 s -> 318857-05-20T17:46:40.000Z * 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.