Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chrono::MAX_DATETIME is not deserializable via parse_from_rfc3339 #641

Open
Veetaha opened this issue Jan 4, 2022 · 2 comments
Open

chrono::MAX_DATETIME is not deserializable via parse_from_rfc3339 #641

Veetaha opened this issue Jan 4, 2022 · 2 comments

Comments

@Veetaha
Copy link

Veetaha commented Jan 4, 2022

Steps to Reproduce

Run the following code (playground)

use std::str::FromStr;
use chrono::{DateTime, Utc};

fn main() {
    let max_dt = chrono::MAX_DATETIME;
    
    let str = max_dt.to_rfc3339();
   
    // This works fine though
    assert_eq!(max_dt, DateTime::<Utc>::from_str(&str).unwrap());
    
    // But this panics on `unwrap`
    assert_eq!(max_dt, DateTime::parse_from_rfc3339(&str).unwrap());
}

Context

Our code creates a timestamp with the maximum value to represent a record that never expires and it fails at deserialization. We are going to use regular from_str to workaround the problem, but still I'd expect DateTime::parse_from_rfc3339(dt.to_rfc3339())) to be purely an identity conversion. Is it a bug or is it intended?

Offtopic Context

I am using RFC3339 representation to store the timestamp in a DynamoDB database string property to have it lexicographically sortable. As I see all values after 9999 year have a plus sign and a variable amount of digits in the year. Unfortunately, it messes up the monotonic nature of this format =(. I guess we will have to just accept that we can't have timestamps properly sorted for years more than 9999 just because we will never have such values during our lifespan. Do you have any suggestions for a better solution for this particular problem?

@Veetaha Veetaha changed the title chrono::MAX_DATETIME is deserializable via parse_from_rfc3339 chrono::MAX_DATETIME is not deserializable via parse_from_rfc3339 Jan 4, 2022
@djc djc added the API-incompatible Tracking changes that need incompatible API revisions label Mar 23, 2022
@djc
Copy link
Contributor

djc commented Mar 23, 2022

I think this is a bug in the to_rfc3339() implementation: anything that's not a 4-digit year does not appear to be a valid RFC date. Problem would be that changing to_rfc3339() to be fallible would cause the API to be incompatible. Something to think about...

@pitdicker
Copy link
Collaborator

pitdicker commented Jul 2, 2023

So the issue is that RFC 3339 doesn't support dates beyond 0..=9999.

I opened #1144 to replace to_rfc3339() with to_iso8601 (which does support arbitrary years if preceded by a sign) and a fallible try_to_rfc3339

@pitdicker pitdicker added formatting and removed API-incompatible Tracking changes that need incompatible API revisions labels Jul 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants