@burntsushi is it pronounced yiff?
it’s pronounced: “jiff”
From
COMPARE.md
:Conversely, in Jiff, all time zone lookups by name are cached.
Is the cache invalidated if system tzdata is updated?
And what effect does the answer have on the example from “Jiff supports detecting time zone offset conflicts” if both zoned datetimes used the system timezone which got updated between 1. opening 2. parsing the two zoned datetimes.
Jiff losslessly roundtrips time zone aware datetimes
In this section, wouldn’t be more realistic for
chrono
users to use timezone info around the wire instead of on the wire, rather than usingLocal
+FixedOffset
?In this section, wouldn’t be more realistic for
chrono
users to use timezone info around the wire instead of on the wire, rather than usingLocal
+FixedOffset
?They do say that the difference is that
chrono
users would need to keep out-of-band timezone information in addition to the datetime, whereasJiff
does it in-band.That’s fine. I didn’t look at the code, but from what I gather,
Jiff
serializes the timezone name (not detailed tz info).chrono
users would communicate the same thing, but it’s not built-in functionality in the dt type itself.The example I referred to however may imply that
chrono
users would be inclined do the wrong thing, and get the wrong result as a sequence.(humble personal opinion bit) It feels like it’s a case where the example was pushed a bit extra to fit into the “jump into the pit of success/despair” reference. A reference many, young and old, wouldn’t recognize, or otherwise wouldn’t care for anyway.
You should look at it, they say the implement RFC 9556 timestamps, which include tz info. In my experience it IS useful in real use, because a fixed offset timestamp can lose a bit of information.
For example, if you have a timestamp and want to add a few months to it, for example for a reminder, you will get a timestamp at the same time in the same offset. In many cases that will be wrong, because of things like daylight savings time, which change the offset of the timezone. You will get a timestamp an hour before or after the moment you intended, and it will be in the “wrong” offset in that timezone in that time of year. With timezone aware timestamps, they are aware that the offset will change, and will be able to give a timestamp in the future at the correct time and offset.
I really likes this package. And I may use it immediately. Very complete and detailed documentation. It lacks in some conveniences like iso8601, rfc3339 or other presets for formatting. But those can be handled manually. Thanks for this!
You should absolutely not need to handle ISO 8601 and RFC 3339 manually. They are supported via the
Display
andFromStr
trait implementations on every main type in Jiff (Span
,Zoned
,Timestamp
,civil::DateTime
,civil::Date
andcivil::Time
). It’s technically an implementation of a mixture of ISO 8601, RFC 3339 and RFC 9557, but the grammar is specified precisely by Temporal. See: https://docs.rs/jiff/latest/jiff/fmt/temporal/index.htmlSpeaking of convenient things best not handled manually, do you have any plans to get support for it into crates like sqlx-postgresql, diesel or humantime where conversions need to happen but pretty much the same way for every user of the library?
Yeah this is a tough one. I’m not sure the right thing to do is for me to go around blasting PRs at those projects. They’re probably already carrying support for both
chrono
andtime
, and asking them to support a third that is brand new is a bit of a stretch I think. Especially since I’ve promised breaking changes in the not-too-distant future. (Although I would like to do a Jiff 1.0 release about 1 year from now and commit to stability.) At least, I know I’d be hesitant if I were on the other side of it. But maybe folks are more flexible than me, I’m not sure.I’ve been noodling on just adding these integrations to
jiff
itself. I do worry that if I do that, then the integrations will always stay with Jiff, even at 1.0. But maybe there just isn’t another feasible choice.But, why do you mention
humantime
?humantime
doesn’t have any integrations withtime
orchrono
.humantime
is more like a thin wrapper on top ofstd::time::Duration
andstd::time::SystemTime
to make parsing and printing a bit nicer.