add more datetime crates

[poopsicles]

closes #150

[poopsicles]

still unsure whether to add humantime, given that its a bit dusty rn, there's cyborgtime, but it doesn't have that many users

and tbh, most people who need that functionality will look up "how to parse human friendly time format chrono" and make the choice anyways

[djc]

I think this is a good set of additions, thanks!

[nicoburns]

This might be controversial, but reading through https://github.com/BurntSushi/jiff/blob/master/COMPARE.md and BurntSushi/jiff#63, I think I'd be inclined to recommend jiff as the primary recommendation.

Dealing with timezones properly is a super important aspect of a date/time library, and it seems that only jiff is doing it properly.

Combine that with:

• Burntsushi's reputation
• jiff being heavily based on Temporal
• The fact that nobody really seems to have been happy with time or chronos API

And it seems like the best pick?

It's less popular, but if we were just basing things on download count this site would be pointless (people could just sort by downloads on crates.io or lib.rs).

That said, I still think there's not a clear winner here. And our aim should be to work out when each library might be most appropriate. And/or what sort of user might want to use each (e.g. prioritising correctness vs nice API vs performance vs binary size). And ideally communicate all of that information to readers of blessed.rs

[djc]

(Noting somewhat of a conflict of interest here: I am the chrono maintainer right now -- although maintenance is pretty passive currently and I mostly started because no one else was taking care of it.)

Making jiff the recommended/first option in the primary list makes sense to me, although I think due to their popularity we should also keep chrono and time there.

[nicoburns]

Agree that chrono should remain in the list. And if you have arguments for why or when chrono is better, then please do feel free to make the case for it!

[BurntSushi]

One of the major benefits of chrono and time at present is their ecosystem integration. Jiff just doesn't have that (yet).

[BurntSushi]

FWIW, I used this style of description (described in terms of other projects) with ripgrep when it was released ("it's like grep and ag") and I kinda regret it. Consider that if you're looking at this list for crate recommendations, you probably don't already know about time and chrono. And so describing Jiff, in brief, with what it isn't, probably doesn't help too much. On the other hand, there really isn't the space here (as is intended) to do even a concise cost/benefit analysis.

It is very hard to do this in one sentence, but here's my crack at it:

A datetime library with automatic tzdb integration and convenient daylight saving time calendar arithmetic, but currently lacks some of the ecosystem integration that time and chrono have.

[nicoburns]

One of the major benefits of chrono and time at present is their ecosystem integration. Jiff just doesn't have that (yet).

Oh wow, to back this up, chrono currently has 12000+ crates that depend on it directly. Compared to 3000+ for time and 64 for jiff.

[djc]

Oh wow, to back this up, chrono currently has 12000+ crates that depend on it directly. Compared to 3000+ for time and 64 for jiff.

I suspect the difference would be less pronounced for currently maintained/recent crates, but definitely a decent reason to keep chrono/time on the list.

[poopsicles]

• The fact that nobody really seems to have been happy with time or chronos API

And it seems like the best pick?

True, it does seem like the best pick for new projects.

...I'm thinking the extra cruft can be moved into the notes, so it looks something like:

jiff is the best option if you're starting a new project, but it currently lacks some of the ecosystem integration that time and chrono have.
Unfortunately, there isn't a clear answer as to which is better between time and chrono.
Evaluate for yourself between the two, but be reassured that both are trusted and well-maintained.

jiff
A relatively new general-purpose datetime library with automatic time zone database integration and convenient zone-aware calendar arithmetic.

time [docs]
A smaller, simpler library. Preferable if covers your needs, but it's quite limited in what it provides.

chrono [docs]
A more comprehensive and full-featured datetime library, but with additional complexity because of it.

See also (click to open)

icu_datetime [docs]
A library focused on providing support for datetime internationalization using the International Components for Unicode. The icu crate re-exports this along with other ICU-focused crates, so you might want that instead.

hifitime [docs]
An ultra-precise datetime library focused towards scientific applications.

[poopsicles]

Also, would it make sense to add a "docs" value in the json so that crates that have an external link (e.g. to route away from lib.rs or because they're not on crates.io) but still have documentation somewhere could have a docs button?

jiff and temporal are affected by the lib.rs thing,,,but then the libraries/tools that get linked to GitHub (e.g. nextest), miss out on documentation even though they do have them (e.g. here)

Could make it a separate PR if that makes sense

[djc]

time [docs] A smaller, simpler library. Preferable if covers your needs, but it's quite limited in what it provides.

chrono [docs] A more comprehensive and full-featured datetime library, but with additional complexity because of it.

I don't agree with these relative characterizations. It feels to me like time and chrono have a pretty similar scope, but chrono maintains a relatively conservative MSRV, isn't split across as many utility crates, and is pretty boring/straightforward. On the other hand, many time versions broke when 1.80 was released due to what I perceive as heavier reliance on subtleties of the language/compiler.

(time has unconditional dependencies on deranged, num-conv, powerfmt and time-core -- all from the same maintainer. chrono only depends on num-traits by default.)

[poopsicles]

On the other hand, many time versions broke when 1.80 was released

I remember that happening, and tbh, it kinda sounded like the internal team did a crater run, saw that stuff would break and went "well there's a newer version of time out that uses the correct annotations, they'll all update", like I don't think it was time's fault for using "subtleties of the compiler" (it was just an ::Into call afaik)

And hm, I guess you're right about the relative characterisations...those were written a long time ago and haven't really been changed...especially with the whole time 0.2 thing (reading the chrono docs page lol)

Thinking of pinging jhpratt to see what he has to say about things, though he already commented in chronotope/chrono#1423 so I'll give that a read and try and come up with different sentences.

[BurntSushi]

I think given that we have Chrono and Jiff maintainers discussing things here, the right thing to do is to ping @jhpratt.

I'll also ping @ChristopherRabotin as the maintainer of hifitime.

And @sffc for a point of contact for icu_datetime.

[sffc]

The icu_datetime description looks about right; thanks!

[jhpratt]

Burntsushi's reputation

While no reasonable person would dispute his reputation, I will point out maintainers of all three crates are permitted to merge (certain types of) code into the Rust project itself.

The fact that nobody really seems to have been happy with time or chronos API

Asking sincerely — where are you getting this from? While mistakes have certainly been made with regard to API design, they are largely being rectified. I have a private list of changes that I have considered or are planning to make in the future. I wouldn't be surprised if chrono has something similar.

---

It feels to me like time and chrono have a pretty similar scope

Agreed. jiff goes a bit farther than both in my opinion, though at least personally I've been working on a handful of new features in time for more advanced use cases. There is third-party tzdb integration, so it's not a critical feature missing in my view.

My suspicion is that the "simpler, smaller" bit is a remnant from time 0.1, which had a significantly smaller scope.

On the other hand, many time versions broke when 1.80 was released due to what I perceive as heavier reliance on subtleties of the language/compiler.

Eh, that's hardly my fault. I had .into() that implicitly relied on there only being one destination type, but no lint existed to catch this situation. A crater result showed the significant breakage but the new trait impl was merged anyway. It was a systematic failure from T-libs-api and is being addressed on multiple fronts. I wouldn't call .into() a "subtlety".

(time has unconditional dependencies on deranged, num-conv, powerfmt and time-core -- all from the same maintainer. chrono only depends on num-traits by default.)

While true, all of these crates either originated in time or were designed due to needs that I had with time, only being published separately because they could be useful for others. libification also helps with compilation speed (though it's pretty fast already).

---

I think given that we have Chrono and Jiff maintainers discussing things here, the right thing to do is to ping @jhpratt.

For the record, I was contacted off-GitHub to be made aware of this thread 🙂

---

Overall, I'm not opposed to this change as it improves on the status quo by including additional crates. With that said, updating the language for existing crates probably isn't a bad idea.

[poopsicles]

jiff is the best option if you're starting a new project...
...but it currently lacks some of the ecosystem integration that time and chrono have.
Unfortunately there is no clear answer as to which is better between time and chrono.
Evaluate for yourself between the two, but be reassured that both are trusted and well-maintained.

jiff [docs]
A relatively new general-purpose datetime library with automatic time zone database integration and convenient zone-aware calendar arithmetic.

time [docs]
A powerful, popular datetime library with an easy-to-use API, helper macros, and smaller binary size.

chrono [docs]
The more comprehensive datetime library, with support for extra crates (like tzfile and chrono-tz) providing additional features like timezone conversions.

---

Removed the "smaller simpler" bit in time since it's mostly as powerful as chrono now.

Then emphasised chrono's extensibility and timezone stuff (but that'll change if/when time adds support for that).

[BurntSushi]

I would drop "more comprehensive" from chrono's description personally. That might have made sense in a comparison with just time, but doesn't with Jiff.

[jhpratt]

time has time-tz as well, so there is (third party) integration for those that need it.