19 ms·
If I'm not mistaken "chrono"[1] behaves almost the same. It calls Local[Date|Time|DateTime] Naive[Date|Time|DateTime]. ZonedDateTime is just called DateTime. It
by dthul 6y ago
If I'm not mistaken "chrono"[1] behaves almost the same.
It calls Local[Date|Time|DateTime] Naive[Date|Time|DateTime]. ZonedDateTime is just called DateTime. It doesn't have a separate type for Instants but can convert (zoned) DateTimes to and from UNIX timestamps.
[1] https://docs.rs/chrono/0.4.19/chrono/index.html https://docs.rs/chrono/0.4.19/chrono/index.html
Edit: it seems like chrono's design took lessons learned from other time libraries, including JSR-310, into account, so that explains why they are so similar.
- kuschku 6y agoYeah, Chrono is also really nice, indeed. Didn’t know it was inspired by JSR310, but it makes sense now that I think about it :) The new ES Temporal API is also inspired by the same API.
- rofrol 6y agoI think this crate should be used now https://time-rs.github.io/time/index.html https://time-rs.github.io/time/index.html
- dthul 6y agoI haven't heard of it before! Do you know what sets it apart from chrono? It doesn't mention anything in the readme as far as I can tell.
- lifthrasiir 6y agoThe biggest difference between time-rs and Chrono to me is the inlined time zone type parameter. Chrono's `DateTime<FixedOffset>` is called `OffsetDateTime` in time-rs. The intention was to be able to specialize `DateTime` to the permanent UTC time zone and avoid any offset calculation, but this idea has never caught on. Also time-rs has a luxury of procedural macros which didn't exist when Chrono was first designed.
- lifthrasiir 6y agoJoda's Instant corresponds to `std::time::SystemTime` in Rust. It was never intentional (source: I designed Chrono and it existed before `std::time`), but currently Chrono fills the calendar date and time while the standard library fills the monotonic and wall-clock timestamps. To be honest, I think JSR-310 is not correct in every regard and its implementation of every ISO 8601 format is a mistake. I even started out Chrono without referring to JSR-310 (because I have designed other date and time libraries in the past). But it is much better than, say, Python datetime to which is being compared.
- elygre 6y agoI'm interested in learning more about the ISO 8601 format issue. Can I read more about that anywhere?
- lifthrasiir 6y agoJSR-310 contains lesser-useful fragments of ISO 8601: MonthDay, Period, Year, YearMonth, Month. They might be useful if they are agnostic to calendar systems, but they are actually just for ISO 8601. Period is doubly problematic. It is important to realize that ISO 8601 is the standard for interchange formats, not the standard for computer data types (compare to, say, IEEE 754). As a result you need additional information to make it a proper data type standard. For ISO 8601 period you would need the actual algorithm to add it to a time point. What happens if you add 1 month (P1M) to January 30, 2021 (2021-01-30)? Would it be 2021-02-28 or 2021-03-02? Should we give both options to end users? You need a set of pluggable policies to make it work. JSR-310 Period class is pretty lacking in this regard. (In fact, pretty much every implementation of "relative delta" has the same problem. It can't be readily used in the business logic.)
- CodesInChaos 6y agoIMO SystemTime should be avoided in its current state. The API is extremely limited and annoying to use for no good reason. And what's worse is that both precision and range depend on the platform.