Feedback to upgrade jiff to 0.1.16

[tisonkun]

Hi @BurntSushi! Thanks for your continuous work and the recent f6fc1b0 and 1e39b60 released in 0.1.16.

I have upgraded jiff to 0.1.16 for our database software. Here is the patch to demonstrate that the changeset (from 0.1.13) is relatively small: https://gist.github.com/tisonkun/183e761fdf8d26a4799f91f6ba3cbe80

Briefly, we use SignedDuration as the internal representation of the database's Interval type, and now try to use it in the HTTP request to reduce the dependency to humantime/humantime-serde.

Here are three remaining issues I'm considering now.

1. Converting SignedDuration to std's Duration introduces some boilerplate code.

Although I think this is by design (std's Duration is unsigned), the .try_into.map_err/.try_into.except is a bit noisy.

Ecosystems like tokio don't integrate with jiff's type (yet?), so we have to manage such boilerplate code in the application.

2. Support Span as the representation of a new interval type.

We use SignedDuration as the internal representation because it has a natural mapping from/to nanoseconds. While with Span, we may need to store the whole string or a few of accurate parts. In the upside, Span allows user to specify intervals with days, months, years, etc., which can be more intuitive in some case.

Software like Apache Arrow has multiple types for duration and interval and that may be the way to go.

• https://docs.rs/arrow/latest/arrow/datatypes/struct.IntervalMonthDayNano.html
• https://docs.rs/arrow/latest/arrow/array/type.DurationNanosecondArray.html

3. Eliminate sqlx_jiff internal wrapper.

This is unrelated to 0.1.16 but we're now internally maintain a mod to do the same thing exactly for what #141 does. If it can get some reviews, it would be great :P

Thanks again for this wonderful crate. I find it quite ergonomic and has the minimum friction to use.

[tisonkun]

For anyone who would like to upgrade to 0.1.16 and have an option to switch back the previous format, check out https://docs.rs/jiff/latest/jiff/fmt/temporal/struct.SpanPrinter.html.

[BurntSushi]

For anyone who would like to upgrade to 0.1.16 and have an option to switch back the previous format, check out https://docs.rs/jiff/latest/jiff/fmt/temporal/struct.SpanPrinter.html.

You shouldn't need to use this unless you specifically only want to support the ISO 8601 format. Otherwise there is no change to what Jiff does in semver APIs other than FromStr and Deserialize accepting more inputs.

[tisonkun]

I agree with your statement. My assumption is, now the format of SignedDuration, said in {dur:?} becomes 59s 778ms 800µs and 26h 59s 778ms 800µs ago. When people may want to print PT59.7788s and -PT26h59.7788s, temporal::SpanPrint is an exit. Or perhaps {dur} does the same?

[BurntSushi]

{dur:?} is the Debug format. Like with std, there aren't any API guarantees about its specific output format. In contrast, the Display impl format is an API guarantee. So {dur} is always guaranteed to be ISO 8601 (in a semver compatible release, although I don't expect to change it in future semver incompatible releases).

[tisonkun]

So if I'd like to use the friendly format stably, instead of depending on {dur:?}, should I use friendly::SpanPrinter? Or if {dur:#} is promised not to change in a compatible version bump.

[BurntSushi]

{dur:#} being the friendly format is a semver guarantee. Display impls are supposed to be stable parts of APIs.

You really should only need friendly::SpanPrinter when you want to customize the output or have more control over what it writes to.

[BurntSushi]

For (3), I consider that part of ecosystem integration. My focus hasn't really shifted to that yet.

For (2), is there any actionable feedback there? I'm not clear on what you're saying exactly. :)

For (1), do you have any alternative suggestions? The conversion from SignedDuration to Duration is fallible. So there has to be an error path in there somewhere.

[BurntSushi]

You can invent a binary serialization format, to be clear, but it should capture every unit value.

[BurntSushi]

After thinking about this more, I think a clarification is important: you can use (months, days, nanos) to represent a Span if you don't care about the difference between 36 months and 3 years. They are precisely equivalent durations in terms of real time passed, but they might express different flavors of time passage. For example, you might want to always represent the length of films in terms of minutes, even if exceeds multiple hours, as is convention in the US at least. The only way to preserve that expressive power is to serialize all units as they are.

It all depends on your requirements.

[tisonkun]

Thanks for your information.

They are precisely equivalent durations in terms of real time passed.

Yes this is the point I'd like to confirm.

you might want to always represent the length of films in terms of minutes, even if exceeds multiple hours, as is convention in the US at least

Good to know.

The rest part would be how such Spans get compared and checked equality. I found there are several docs to read the test, but generally, (1) equality is checked by exact field matches (as derived), and (2) compare is done faillable, depending on the unit in use. Is this the case?

[BurntSushi]

The compare method uses the actual time passed.

The Eq and PartialEq impls will be removed in jiff 0.2 since they are a footgun. There's an open issue about it.

[tisonkun]

Get it.

For cross reference - #32.