Skip to content

Saturate From<SystemTime> for DateTime<Utc> instead of panicking - #1811

Open
n0liu wants to merge 1 commit into
chronotope:mainfrom
n0liu:fix-timedelta-checked-sub-overflow
Open

Saturate From<SystemTime> for DateTime<Utc> instead of panicking#1811
n0liu wants to merge 1 commit into
chronotope:mainfrom
n0liu:fix-timedelta-checked-sub-overflow

Conversation

@n0liu

@n0liu n0liu commented Aug 6, 2026

Copy link
Copy Markdown
Contributor

Addresses the From<SystemTime> finding in #1802.

From<SystemTime> for DateTime<Utc> is infallible at the type level, but it unwraps Utc.timestamp_opt(...), so a SystemTime outside the range of DateTime panics:

let t = UNIX_EPOCH + Duration::from_secs(i64::MAX as u64 - 1);
let _: DateTime<Utc> = t.into(); // panics at datetime/mod.rs

Since the conversion cannot return an error, this saturates to DateTime::<Utc>::MAX_UTC / MIN_UTC for out-of-range inputs instead of panicking. Normal values are unaffected.

If you would rather document the panic (or make the conversion fallible) than saturate, I am happy to change direction.

Added assertions to test_from_system_time. Full test suite, cargo fmt, clippy -D warnings, and --no-default-features all pass.

`From<SystemTime> for DateTime<Utc>` is infallible at the type level but
unwrapped `Utc.timestamp_opt(...)`, so a `SystemTime` outside the range
of `DateTime` panicked. Saturate to `MAX_UTC` / `MIN_UTC` for
out-of-range inputs instead; normal values are unaffected.

Addresses the `From<SystemTime>` finding in chronotope#1802.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants