Experiences when adapting rustic to jiff

[aawsome]

Hi @BurntSushi

I adopted my project to use jiff (see rustic-rs/rustic_core#452; mainly to get rid of the humantime dependency which has a RUSTSEC warning) - and must say that I really like what you have done! The structs are very easy and intuitively to use. Also it automatically made me think of edge cases and using the very good and structured docu, I learned a lot about date/time handling and stumbling block in this area ;-) Great job!

So, most things went very smooth, however there are 2 things I want to mention here:

• The format we are using saves times in a format like "2025-12-26T20:27:14.962535153+01:00". Now, I've learned that this is actually a bad idea, however, alas , changing this is not possible as it would break backwards compatibility and restic compatibility. So, I had to write my own parser/serializer, see https://github.com/rustic-rs/rustic_core/pull/452/files#diff-503d9055416fab688f096fb1d40d17e827daf7013759d4a0154edcf9bed851aaR62. I wonder if such a "best-effort-parsing" could be contained directly in jiff...
• When doing calculations on day_of_year() or month(), you sometimes need results starting with 0. chrono had the 0 variants, e.g. month0() (see https://github.com/rustic-rs/rustic_core/pull/452/files#diff-1d3e32348f9171504c88f13ddac1b4552da512c4525bdcdc042e5ce1029736cfR109) - would that be something to add to the jiff API?

[BurntSushi]

Thank you for the feedback! I'm glad to hear that things mostly went well. :-)

For month0 and similar, I'm not especially inclined to clutter up the API with these sorts of methods everywhere. There is some support for it for Weekday because there are multiple popular conventions. But for something like month(), the 1-index variant is by far the most common and what you usually want. For folks that need the 0-index variant, I'm inclined to have them do the subtraction. The Jiff docs provide guarantees on the range of values returned, so a simple date.month() - 1 is always correct and will never overflow.

For things like 2025-12-26T20:27:14.962535153+01:00, I was going to say that you should definitely not need to write your own parser for this. But looking at your PR, you aren't writing your own parser. You're using jiff::fmt::temporal::Pieces, which is exactly what I was going to suggest. I do acknowledge that there is some setup involved here and boiler-plate to integrate nicely.

For "best effort parsing," I've actually written my own variant of this for Biff: https://github.com/BurntSushi/biff/blob/f33954f27c86644d59ad283ce753b992ac40a82f/src/datetime.rs#L363-L426

I am not, at present at least, inclined to add something like this to Jiff. I think it's better that Jiff adhere to interoperable formats with specifications for them. (The "friendly" format is the only thing in Jiff that is bespoke. But there were, IMO, very compelling reasons to add that.) I think "best effort" approaches can get folks into trouble. As you say, you've learned that just date + time + offset is not really ideal. The fact that Jiff doesn't have a paved path for that format for Zoned is quite intentional. Indeed, this was a design decision I took from Temporal.

I think that if something like that is ever added, it will probably come in the form of an opt-in TimestampWithOffset kind of type. But the only thing that buys you is avoiding the use of the lower level Pieces API. You'd still have to do work to get your "best effort" parse.

[aawsome]

Thanks for your remarks!

About month0() etc: I just realized shortly after writing, that the calculations done with it in rustic are actually quite error-prone: We use something like "number of current hour in current year/month/week" vs. "total count of hours in current year/month/week" and assume that days have 24 hours. Which of course is not always true. So, computing differences between a "first hour in current year/month/week" and current time or "last hour in current year/month/week" would be the accurate approach - which is of course perfectly supported by jiff..
(In our case potential errors are non-critical and I think we stay compatible with the incorrect former computation, for the moment at least)

About parsing/serialization you are right - I meant I had to write own wrappers for integrating the Pieces parser and DateTimePrinter - especially as I needed/wanted to parse Option<Zoned> via serde_as. I agree that this kind of wrapper boilerplate would most likely be needed for any kind of "best effort parsing" jiff would offer. Using Pieces was very pleasant, actually! The new best-effort parsing already adds more features by allowing users to specify incomplete dates, which is not possible at the moment. After seeing your implementation, I think I'll enhance the parsing even more to add support for durations implicitly taken relative to Zoned::now() - thanks a lot!