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

Differences between this crate and time #1423

Open
frederikhors opened this issue Feb 10, 2024 · 14 comments
Open

Differences between this crate and time #1423

frederikhors opened this issue Feb 10, 2024 · 14 comments

Comments

@frederikhors
Copy link
Contributor

I'm new to Rust and I'm wondering: what substantial differences are there between this crate and time?

@pitdicker
Copy link
Collaborator

pitdicker commented Feb 10, 2024

As a mini-history, glossing over all details: before the release of rust 1.0 time-rs had the simple platform interfaces, and chrono was the date-time library. At some point time-rs was deprecated and chrono absorbed its functionality. Then chrono became unmaintained for a while, and time-rs became a new crate with a simplified part of chrono's API. Now both are actively developed again.

Chrono 0.4.33 vs time 0.3.34

feature Chrono 0.4.33 time 0.3.34
date type NaiveDate Date
time type NaiveTime Time
date and time type NaiveDateTime PrimitiveDateTime
date, time and offset from UTC DateTime<FixedOffset> OffsetDateTime
date and time in UTC DateTime<Utc> (Utc is a ZST) OffsetDateTime
date and time, offset and associated timezone DateTime<Tz> --
formatting and parsing format strftime-inspired custom (nice) format
converting between time zones (not just offsets) yes no
handles results in DST transitions correctly yes no
compile-time IANA database via chrono-tz in progress
parsing and formatting RFC 2822 complete complete(?)
parsing and formatting RFC 3339 complete complete
formatting and parsing ISO 8601 no (open PR) yes
localization unstable, formatting only no
API needs new major version to match current standards quite ergonomic
initialization and basic operations are const yes yes
macros for easy initialization no yes
serde yes yes
fix for CVE-2020-26235 pure-rust implementation requires single thread or platform guarantees for soundness

I am of course biased. In my opinion chrono has the better implementations (this is all not meant as bragging, it is not designed by me). Unique features: Operations on dates can be very fast thanks to a smart internal representation. Chrono can correctly recognize tricky invalid cases when parsing (see the Parsed documentation). It can handle time zones and all the complexities that come with that. Our platform code can handle more tricky cases.

On the other hand chrono is quite old and predates current API standards. Time is more ergonomic to use at the moment, at least until chrono 0.5. Chrono uses the not-that-readable strftime format for formatting and parsing; you may like the functionality of time-rs better.

Consider also asking for the time crate (time-rs/time#308) for less bias 😄.

@djc
Copy link
Member

djc commented Feb 10, 2024

chrono has a much more conservative MSRV. time is increasingly splitting out more dependencies.

@djc
Copy link
Member

djc commented Feb 10, 2024

I would say you basically can't go wrong with either. time is a bit more popular right now.

@jhpratt
Copy link

jhpratt commented Feb 10, 2024

Corrections/clarifications on my end (as maintainer of time):

handles results in DST transitions correctly

This is because DST transitions do not exist in fixed-offset implementations.

compile-time IANA database

In progress!

date and time in UTC

OffsetDateTime can handle this, although I actually have been working on a new type recently.

parsing and formatting RFC 2822

time supports the full RFC, including all deprecated parts. If you have a counterexample, please let me know.

formatting and parsing ISO 8601

This is fully supported.

fix for CVE-2020-26235

The "user guarantee" is not the case. Soundness is guaranteed. The only exception is if someone falsely asserts (in an unsafe context!) that they are upholding the soundness requirements.

@jhpratt
Copy link

jhpratt commented Feb 10, 2024

chrono has a much more conservative MSRV. time is increasingly splitting out more dependencies.

chrono is 1.61; time is 1.67. That's not a huge difference. 1.67 is still a year old. The policy is different (does chrono have anything concrete?), but the reality is that I have not had a reason to bump MSRV in quite a while.

@djc
Copy link
Member

djc commented Feb 10, 2024

chrono is 1.61; time is 1.67. That's not a huge difference. 1.67 is still a year old. The policy is different (does chrono have anything concrete?), but the reality is that I have not had a reason to bump MSRV in quite a while.

Oh, that is a much smaller difference than I thought, nice! Still wary of the policy, though.

@jhpratt
Copy link

jhpratt commented Feb 10, 2024

I keep track of a number of features. #![feature(int_roundings)] is the only item currently set for a bump, though I have yet to check whether the stabilization is what's actually needed internally, given that it was a partial stabilization. Even then, I probably wouldn't bump it for just that.

Ultimately I don't see the MSRV being bumped in the near future, as nothing being tracked is close to stabilization and has sufficient impact.

@pitdicker
Copy link
Collaborator

Corrections/clarifications on my end (as maintainer of time):

Nice, good to have your input @jhpratt!

handles results in DST transitions correctly

This is because DST transitions do not exist in fixed-offset implementations.

Yes. Not meant as critique of time. Dealing with this just might be a feature someone would want and could help choosing a library.

date and time in UTC

OffsetDateTime can handle this, although I actually have been working on a new type recently.

parsing and formatting RFC 2822

time supports the full RFC, including all deprecated parts. If you have a counterexample, please let me know.

At the time I though I missed something with the timezone names, but haven't found the relevant parts back agin in your crate.

formatting and parsing ISO 8601

This is fully supported.

Really? Nice.

fix for CVE-2020-26235

The "user guarantee" is not the case. Soundness is guaranteed. The only exception is if someone falsely asserts (in an unsafe context!) that they are upholding the soundness requirements.

I guess we can call it: 'requires single thread or platform guarantees for soundness'

I'll update the table in my comment. It came from some notes while I was looking into the differences for myself, and wanted to give something mostly right instead of nothing 😄. Good to have some form of comparison anyway.

@pitdicker
Copy link
Collaborator

I would say you basically can't go wrong with either. time is a bit more popular right now.

Pretty similar to each other it seems.

Chrono

afbeelding

Time

afbeelding

@jhpratt
Copy link

jhpratt commented Feb 12, 2024

Yes. Not meant as critique of time. Dealing with this just might be a feature someone would want and could help choosing a library.

Absolutely! My remark there was more for context, as it's implied by the other row.

Really? Nice.

It was an open issue for quite a while, but I was able to obtain the 2019 version of the spec (the most recent) when a company purchased it in my name.

I guess we can call it: 'requires single thread or platform guarantees for soundness'

That's a fair way to word it.

It came from some notes while I was looking into the differences for myself

Depending on how long ago it was done, some of the info may have been accurate at the time. It's certainly good to have something, as it's hard to be impartial, particularly given that I haven't used chrono in many years.

@djc
Copy link
Member

djc commented Feb 12, 2024

I would say you basically can't go wrong with either. time is a bit more popular right now.

Pretty similar to each other it seems.

Well, I think 17% more qualifies as a "bit more" -- but yeah, it's definitely same order of magnitude.

@pitdicker pitdicker pinned this issue Feb 12, 2024
@frederikhors frederikhors changed the title What substantial differences are there between this crate and time? Differences between this crate and time Feb 14, 2024
@frederikhors
Copy link
Contributor Author

@pitdicker maybe you can add another important difference in the table: with chrono I can freely use the #[derive(Default)], with time no.

@djc djc unpinned this issue Mar 26, 2024
@tgrushka
Copy link

tgrushka commented Jun 3, 2024

Why are there no conversion options between time and chrono? As a new rust developer, I'm finding trying to figure out chrono to be pretty unnerving and frustrating. For example, using the solar-calendar-events crate:

let equinox: time::OffsetDateTime = MarchEquinox::new(year).unwrap().date_time().unwrap();

Now, I want to convert that from an OffsetDateTime to another time zone. But the time crate does not support that (only offsets). My other code is using chrono, so I have to go through all this to get a time in a particular zone in chrono. Then, how do I even convert from OffsetDateTime to DateTime<Tz>? You'd think this would be simple with the popularity of both chrono and time crates...

let tehran = Tehran
    .with_ymd_and_hms(year, 3, equinox.day() as u32, 0, 0, 0)
    .unwrap();
tehran.with_time(equinox.time());
mismatched types
expected `NaiveTime`, found `Time`

So they seem totally incompatible (without having to convert to/from UNIX timestamp, I guess?).

Time zones and dealing with time are a real pain in most languages, but they don't have to be in Rust, as the compiler should help you. The methods and auto-suggestions on chrono (and chrono-tz) just don't seem intuitive to me, and the documentation lacks many examples on how to just parse time from a database with a dynamic time zone like most people do (how many people really hard-code their timezones in apps?).

But my main point here is that between these two popular crates, there is no way to convert (!!!), while most other languages (Dart, Python, etc.) have centered around pretty standard time structures and good documentation on how to deal with and convert them. Even JavaScript has luxon, which provides a means to convert between it and other types.

@djc
Copy link
Member

djc commented Jun 5, 2024

Due to the notion of coherence in the language, providing conversion routines would mean one of these crates taking a dependency on the other. That would kind of defeat the purpose of picking a single one... So yes, these crates have evolved independently and they are completely "incompatible" at the type system level.

If you have constructive specific feedback on our API or the documentation, we're happy to discuss those in a separate issues.

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

No branches or pull requests

5 participants