mirror of
https://github.com/storytold/filmcraft.git
synced 2026-10-24 01:58:19 -06:00
Dylan M. Taylor
c5c1693989
* Use chrono for UTC/calendar conversion instead of hand-rolled copies Replaces the hand-rolled civil_from_days / days_from_civil copies (app log timestamp, Media Browser date column, auto-save file-name stamp, MXF header timestamp, golden-image attribution date) with chrono as a workspace dependency. The existing chrono entry on apps/filmcraft (clock feature) was lifted to the workspace. Output formats are unchanged and pinned by tests. AGENTS.md now says time goes through chrono. Follow-up to storytold/cadcraft#1785 * Never panic on a clock outside chrono's range; keep 5-digit years unprefixed chrono's From<SystemTime> unwraps internally, so a clock past year 262143 panicked. logging::timestamp and golden::today now read the duration since the epoch and go through the fallible DateTime::from_timestamp, reading an out-of-range or pre-epoch clock as the epoch as the old saturating code did. timestamp, today and media_browser::format_date write the year with {:04} rather than %Y, which prefixes a '+' past year 9999. Tests cover the far-future and year-10000 cases for timestamp and format_date. * 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 out-of-range years instead of the epoch (FredApps review) `DateTime::from_timestamp(..).unwrap_or_default()` changed the existing output: inputs the old hand-rolled civil-from-days converted (e.g. `10_000_000_000_000` s → 318857-05-20 17:46:40) collapsed to `1970-01-01 00:00:00`. Restore the old conversion domain with a cycle-based helper: reduce by whole 400-year Gregorian cycles (146_097 days), convert the in-range remainder with chrono, and carry the year back as i128 (saturating to the output type). Only the year leaves chrono's range; month, day and time of day are always exact. Sites (all UTC): - apps/filmcraft logging.rs `timestamp` (SystemTime, u64 secs): pre-1970 still clamps to the epoch; a far-future clock keeps its year. u64::MAX/2 s → "292277026596-12-04T15:30:07.000Z", 10e12 s → "318857-05-20T17:46:40.000Z" (was "1970-01-01..."). SystemTime cases built with a checked add (Windows-safe). - crates/engine media_browser.rs `format_date` (u64): 10e12 s → "318857-05-20 17:46", u64::MAX → "584554051223-11-09 07:00" (was "1970-01-01 00:00"). - crates/format autosave.rs `civil` (i64 + i32 offset): keeps years, e.g. i64::MAX → 292277026596-12-04 15:30:07, i64::MIN → -292277022657-01-27. The separate `unix + offset_secs` overflow guard (checked_add) is kept: only an overflowing shift (old code wrapped it to garbage) reads as the epoch. - crates/mxf from_unix (i64): keeps month/day/time, clamps only `year` to the u16 field as before. 10e12 s → year 65535, May 20 17:46:40; -10e12 s → year 0, Aug 13 06:13:20. - crates/testkit golden.rs `today` (u64): same helper; pinned via `utc_parts`. chrono stays the only calendar logic (NaiveDate::from_num_days_from_ce_opt on the in-cycle remainder). No new chrono features; still default-features = false, std. * 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.