Is the cache invalidated if system tzdata is updated?
Yes, although at present, there is a TTL. So an update may take “time” to propagate. jiff::tz::db().reset() will force the cache to be invalidated. I expect the cache invalidation logic to get tweaked as we get real experience with it.
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.
New updates to tzdb are only observed when you do a tzdb lookup.
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 using Local+FixedOffset?
That’s kinda my point. How do they do that? And does it work with chrono-tzandtzfile? And what happens if tzdb updates lead to a serialized datetime with an incorrect offset in a future update of tzdb? There are all sorts of points of failure here that Jiff will handle for you by virtue of tighter integration with tzdb as a first class concept.
Yes, although at present, there is a TTL. So an update may take “time” to propagate.
jiff::tz::db().reset()will force the cache to be invalidated. I expect the cache invalidation logic to get tweaked as we get real experience with it.It’s hard to know precisely what you mean. But once you get a
jiff::tz::TimeZone, that value is immutable: https://docs.rs/jiff/latest/jiff/tz/struct.TimeZone.html#a-timezone-is-immutableNew updates to tzdb are only observed when you do a tzdb lookup.
That’s kinda my point. How do they do that? And does it work with
chrono-tzandtzfile? And what happens if tzdb updates lead to a serialized datetime with an incorrect offset in a future update of tzdb? There are all sorts of points of failure here that Jiff will handle for you by virtue of tighter integration with tzdb as a first class concept.