Would you consider a feature flag to use `jiff` over `chrono`?

[felipesere]

Hello,

Would you consider a PR that replaces chrono with jiff behind a feature flag?
The jiff crate is fairly new but a fresh take on time by BurntSushi (from ripgrep, regex and some other crates) that has
been gaining traction.

The jiff repo has a longer section comparing it to the other time crates, and chrono is very close to it.

I personally like BurntSushis technical design, particularly when it comes down to API stability and carrying as few dependencies as possible.

I'd be happy to give this a try if its something that would be considered for merging?
It will also allow upstream crates such as kube-rs to use jiff for its interaction with dates/times.

[Arnavion]

The jiff repo has a longer section comparing it to the other time crates, and chrono is very close to it.

chrono usage in k8s-openapi is only for DateTime<Utc>, so most of the stuff in that comparison doesn't seem to apply. I imagine it won't apply to users either.

---

I'd be happy to give this a try if its something that would be considered for merging?

Sure.

You may want to refer to this branch for pointers. That one was for chrono to time, and also it was a replacement rather than an optional addition, so it's not exactly the same, but at least it should point out all the places that would need to change.

Based on a brief glance at the docs:

• I'm not sure if it'll be better to represent chrono::DateTime<Utc> as a TimeStamp or a Zoned. The latter embeds the fact that it's UTC but we only ever deal with UTC, so the extra metadata is sort of a waste of space. chrono's API is nice in that regard that the TZ is part of the type and its offset is an assoc ty, so it doesn't take extra space over the underlying timestamp. But we're not particularly optimizing for space so maybe it's fine to use a Zoned if that's what the library expects people to use.

• All default features seem like they should be turned off. At most we would need to depend on jiff::tz::TimeZone::UTC (or not even that, depending on the previous point), so we shouldn't need to depend on the system TZ DB nor force one to be embedded. The std feature can be wired up to this crate's std feature. alloc can be enabled always since we always depend on alloc even in no_std, and it seems disabling the alloc feature in jiff brings some harm.

• The &str -> TimeStamp / &str -> Zoned (strptime) and other way around (strftime) API does not seem to have an equivalent where the format string is already parsed, which is unfortunate. Compare with RFC3339_SUBSECONDS_ZERO and RFC3339_SUBSECONDS_SIX in the chrono-to-time branch I linked. That said, the temporal format seems to be close enough to RFC3339 (seems to be a superset for parsing and equivalent for printing UTC) that temporal::DateTimeParser and temporal::DateTimePrinter can be used. The consts for the latter should be created with calls to .precision() so that the const used for Time has zero fractional digits and the one for MicroTime has six.

[BurntSushi]

If you only ever need to use UTC and chrono::DateTime<Utc> is sufficient for you, then you should probably be just fine using jiff::Timestamp. That's what it's meant for anyway. A Unix timestamp is always UTC. At least, I can't think of an obvious reason why you would want to use Zoned instead, unless you're looking to do calendar arithmetic (which cannot be done on Timestamp).

does not seem to have an equivalent where the format string is already parsed, which is unfortunate.

Can you say more about why you want this? I looked at your linked branch briefly but the reason didn't stand out to me.

[Arnavion]

If you only ever need to use UTC and chrono::DateTime<Utc> is sufficient for you, then you should probably be just fine using jiff::Timestamp. That's what it's meant for anyway.

Okay, sounds good.

---

does not seem to have an equivalent where the format string is already parsed, which is unfortunate.

Can you say more about why you want this?

This crate's job is to deserialize and serialize types from JSON, so anything that makes it faster is welcome, and not parsing a format string into a format spec each time the type has to be (de)serialized is one of those things. The situation is analogous to precompiling and reusing a regex instead of recreating it for every execution. That said, there is no benchmark for how much difference it makes, nor is there any well-defined perf target or requirement that the crate needs to meet.

[BurntSushi]

Ah okay, yeah, that's what I figured but wanted to check. Despite the fact that both time and chrono permit parsing their format strings ahead of time (with time doing it at compile time), Jiff's strptime is still faster:

parse/strptime/oneshot/jiff
                        time:   [56.555 ns 56.647 ns 56.742 ns]
                        change: [+0.3773% +0.8151% +1.2338%] (p = 0.00 < 0.05)
                        Change within noise threshold.
Found 5 outliers among 100 measurements (5.00%)
  4 (4.00%) high mild
  1 (1.00%) high severe

parse/strptime/oneshot/chrono
                        time:   [158.18 ns 158.68 ns 159.23 ns]
Found 1 outliers among 100 measurements (1.00%)
  1 (1.00%) high mild

parse/strptime/prebuilt/chrono
                        time:   [83.117 ns 83.254 ns 83.401 ns]
Found 3 outliers among 100 measurements (3.00%)
  3 (3.00%) high mild

parse/strptime/prebuilt/time
                        time:   [111.74 ns 111.85 ns 111.96 ns]
Found 3 outliers among 100 measurements (3.00%)
  3 (3.00%) high mild

With this corresponding to this benchmark.

I don't have a similar benchmark for strftime, but I should probably add one.

Specifically, Jiff can only do the "oneshot" case because you can't separate parsing the format string with parsing the datetime. But even when you prebuild them in chrono and time, Jiff is still a fair bit faster.

In theory, it should be possible for the prebuilt benchmarks in chrono and time to beat Jiff here. But in practice, the actual formatting strings are so simplistic that parsing them while also parsing the datetime ends up being overall insignificant. (This may not be the case for time since its format strings are more sophisticated/explicit, but it's definitely true for the strptime APIs of the world.)

This was intentional design on my part, because now you don't need to worry about whether the formatting strings are pre-compiled or not. You just use them as-is and it's still fast.

[Arnavion]

To be clear, the relevant comparison is not jiff vs chrono, but about jiff with format string parsed every time vs jiff with pre-parsed format string (if it were to exist).

In any case it doesn't matter because the temporal formatters can be used, as I said.