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.
What I meant is, someone who wants to serialize zoned dt info using chrono can basically send a timestamp and a timezone name on the wire, e.g. (1721599162, "America/New_York").
It’s not built-in support. It’s not a single human-readable string containing all the needed info that is being sent on the wire. But it does provide the needed info to get the correct results on the other side. And it’s the obvious solution to do, and it’s doable with trivial wrappers. No Local+FixedOffset usage required. And no wrong results inevitable.
// The serialized datetime has no time zone information,// so unless there is some out-of-band information saying// what its time zone is, we're forced to use a fixed offset:
So I feel like the point you’re making here is already covered by the example comparison I wrote. It’s not built-in, so you have to invent your own interchange format. And since your serialized format doesn’t include offset information at the time the instant was created, it’s impossible to do offset conflict resolution. For example, let’s say you record one year from today in Ukraine:
use jiff::{ToSpan, Unit, Zoned};
fnmain() -> anyhow::Result<()> {
letnow = Zoned::now().round(Unit::Minute)?.intz("Europe/Kyiv")?;
letnext_year = now.checked_add(1.year())?;
println!("{next_year}");
Ok(())
}
And the output:
$ cargo -q r
2025-07-22T17:23:00+03:00[Europe/Kyiv]
And maybe you store this datetime somewhere.
At this point, it’s looking like Ukraine is going to abolish DST for next year. So what happens to that datetime above? It no longer has the right offset. So now you need to choose whether to reject it altogether (the default), respect the offset (even if the civil time changes) or respect the civil time (even if the instant changes).
Why is the full presentation non-ephemerally stored instead of (timestamp, timezoe)?
Is the use-case strictly limited to checking the validity of a future date that was generated with assumptions based on current tzdata info? That’s valid, but quite niche I would argue.
And one can adjust the wrapper to have (timestamp, timezone, assumed_offset_at_ts). But yes, it can be argued that it’s not idiomatic/automatic/antecedently obvious anymore.
Time zone transition changes happen all the time. Once you start storing datetimes in the future, you’re in a bit of a precarious position here. Moreover, this is a standardized interchange format that other libraries will know how to read/write. (It’s relatively newly standardized, but has been used in practice among other datetime libraries.)
I think you also glossed over some of my other points. How do you write your serialization code using Chrono? Does it work with bothchrono-tz and tzfile?
The point is almost never about “it is literally impossible to accomplish task foo,” but rather, it matters how it’s approach and how easy it is to do. And if you have to rely on your users having very specific domain knowledge about this, it’s likely there will be errors. As my design docs state, I didn’t only make Jiff to offer more functionality. I also made it because I felt like the APIs could be better. That’s a very subjective valuation, and I find arguments of the type, “well I can just use the old library in this way as long as I hold it right and it actually works just fine” to be missing the forest for the trees.
I think you also glossed over some of my other points. How do you write your serialization code using Chrono? Does it work with both chrono-tz and tzfile?
Again, to be clear, I’m not saying it’s impossible to do. But in order to do it, you have to build your own abstractions. And even then, you still can’t do it because tzfile doesn’t give you enough to do it. And tzfile has a platform specific API with no caching, so every time you parse a datetime with a tz ID in it, it’s completely reloading the TZif data from disk.
Some of these things are implementation quality issues that can be fixed. Others are library design problems where you can achieve your objective by building your own abstractions. Like do you really not see this as something that shouldn’t be mentioned in a comparison between these crates? You must recognize the difference between what you’re doing and just plopping a Zoned in your struct, deriving Serialize and Deserialize, and then just letting the library do the right thing for you. And that mentioning this is appropriate in the context of the “facts of comparison” because it translates into a real user experience difference for callers.
Like do you really not see this as something that shouldn’t be mentioned in a comparison between these crates? You must recognize the difference between what you’re doing and just plopping a Zoned in your struct, deriving Serialize and Deserialize, and then just letting the library do the right thing for you.
If that’s how it was framed in the comparison, it would have been fine. But my original objection was regarding the Local+FixedOffset example which, IMVHO, toys, if ever so slightly, with disingenuity (no offense or aggression intended, I’m a fan).
OK, fair enough. What should it say instead? Just omit the mention of DateTime<Local>? I used it because it’s literally the only way to derive(Deserialize) in Chrono in a way that gives you DST aware arithmetic on the result without getting time zone information via some out-of-band mechanism.
And the fact that you need to create a wrapper means that some programmers won’t bother to do it, or won’t know they need to do it. The default case handling timezones correctly will reduce potential errors.
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 think you misunderstood me.
What I meant is, someone who wants to serialize zoned dt info using chrono can basically send a timestamp and a timezone name on the wire, e.g.
(1721599162, "America/New_York").It’s not built-in support. It’s not a single human-readable string containing all the needed info that is being sent on the wire. But it does provide the needed info to get the correct results on the other side. And it’s the obvious solution to do, and it’s doable with trivial wrappers. No
Local+FixedOffsetusage required. And no wrong results inevitable.Right. That’s exactly what the code snippet says:
// The serialized datetime has no time zone information, // so unless there is some out-of-band information saying // what its time zone is, we're forced to use a fixed offset:So I feel like the point you’re making here is already covered by the example comparison I wrote. It’s not built-in, so you have to invent your own interchange format. And since your serialized format doesn’t include offset information at the time the instant was created, it’s impossible to do offset conflict resolution. For example, let’s say you record one year from today in Ukraine:
use jiff::{ToSpan, Unit, Zoned}; fn main() -> anyhow::Result<()> { let now = Zoned::now().round(Unit::Minute)?.intz("Europe/Kyiv")?; let next_year = now.checked_add(1.year())?; println!("{next_year}"); Ok(()) }And the output:
$ cargo -q r 2025-07-22T17:23:00+03:00[Europe/Kyiv]And maybe you store this datetime somewhere.
At this point, it’s looking like Ukraine is going to abolish DST for next year. So what happens to that datetime above? It no longer has the right offset. So now you need to choose whether to reject it altogether (the default), respect the offset (even if the civil time changes) or respect the civil time (even if the instant changes).
Here’s an example of when this happened with Brazil abolishing DST: https://docs.rs/jiff/latest/jiff/fmt/temporal/struct.DateTimeParser.html#example-3
Why is the full presentation non-ephemerally stored instead of
(timestamp, timezoe)?Is the use-case strictly limited to checking the validity of a future date that was generated with assumptions based on current tzdata info? That’s valid, but quite niche I would argue.
And one can adjust the wrapper to have
(timestamp, timezone, assumed_offset_at_ts). But yes, it can be argued that it’s not idiomatic/automatic/antecedently obvious anymore.Time zone transition changes happen all the time. Once you start storing datetimes in the future, you’re in a bit of a precarious position here. Moreover, this is a standardized interchange format that other libraries will know how to read/write. (It’s relatively newly standardized, but has been used in practice among other datetime libraries.)
I think you also glossed over some of my other points. How do you write your serialization code using Chrono? Does it work with both
chrono-tzandtzfile?The point is almost never about “it is literally impossible to accomplish task foo,” but rather, it matters how it’s approach and how easy it is to do. And if you have to rely on your users having very specific domain knowledge about this, it’s likely there will be errors. As my design docs state, I didn’t only make Jiff to offer more functionality. I also made it because I felt like the APIs could be better. That’s a very subjective valuation, and I find arguments of the type, “well I can just use the old library in this way as long as I hold it right and it actually works just fine” to be missing the forest for the trees.
Something like this?
It can support tzfile too around the wire if it starts to expose tz names in a future version.
Again, to be clear, I’m not saying it’s impossible to do. But in order to do it, you have to build your own abstractions. And even then, you still can’t do it because
tzfiledoesn’t give you enough to do it. Andtzfilehas a platform specific API with no caching, so every time you parse a datetime with a tz ID in it, it’s completely reloading the TZif data from disk.Some of these things are implementation quality issues that can be fixed. Others are library design problems where you can achieve your objective by building your own abstractions. Like do you really not see this as something that shouldn’t be mentioned in a comparison between these crates? You must recognize the difference between what you’re doing and just plopping a
Zonedin your struct, derivingSerializeandDeserialize, and then just letting the library do the right thing for you. And that mentioning this is appropriate in the context of the “facts of comparison” because it translates into a real user experience difference for callers.If that’s how it was framed in the comparison, it would have been fine. But my original objection was regarding the
Local+FixedOffsetexample which, IMVHO, toys, if ever so slightly, with disingenuity (no offense or aggression intended, I’m a fan).OK, fair enough. What should it say instead? Just omit the mention of
DateTime<Local>? I used it because it’s literally the only way toderive(Deserialize)in Chrono in a way that gives you DST aware arithmetic on the result without getting time zone information via some out-of-band mechanism.And the fact that you need to create a wrapper means that some programmers won’t bother to do it, or won’t know they need to do it. The default case handling timezones correctly will reduce potential errors.