Migrating api's to jiff

[joeydewaal]

This kinda isn't a jiff or even a rust question but might be relevant for people migrating their api's/backends to jiff.

Currently in some api's (axum) I'm using chrono and would love to switch over to jiff. The frontend sends a date (default javascript Date object serialized with RFC 3339) in json format, then a handler deserializes it into a chrono::DateTime<Utc>. The interop between js (browser) and rust is seamless here.

When switching to jiff I reach for jiff::Zoned in my handlers since this holds the most information and is the most powerful. This however doesn't work with an RFC 3339 string. I understand why but, what's the solution here?

• I can try to hand roll my own RFC 8536 serializer from the js side with the Intl api's but that's not ideal.
• Alternatively I could deserialize into a jiff::Timestamp and use in_tz but that would mean I have to assume a timezone on the backend.
• The Temporal api's from the js side aren't stable so that's also not an option.

I can't imagine that I'm the only one running into this problem or am I overlooking something? Any insight or solution would be appreciated. Also jiff has been pretty great so far!

[BurntSushi]

Alternatively I could deserialize into a jiff::Timestamp and use in_tz but that would mean I have to assume a timezone on the backend.

This is what I would suggest. The part that isn't clear to me is how you're getting a time zone today. RFC 3339 doesn't support time zones.

So I would just suggest deserializing into a Timestamp and using that directly. If you don't have a time zone, then you don't need to use Zoned.

[joeydewaal]

I'm actually doing that currently, I'm using chrono_tz to assume a time zone when I have to do any arithmetic. It just feels a bit wrong, I'd rather just have a Zoned. But yeah maybe the solution is to use a jiff::Timestamp and treat it as if it's immutable and assume a timezone only when doing any arithmetic.

[BurntSushi]

What does "assume a time zone" actually mean? It's honestly very hard to give you good advice without higher level context on the problem you're solving. Like, if you're doing arithmetic on behalf of an end user, then you should be using that user's time zone. And if you can, yes, use a Zoned everywhere in that case. But if you're just working in UTC and you always want things like "1 day" to be 24 hours, then just sticking with Timestamp and never using Zoned makes sense.

If you know what the time zone is at deserialization time but you get an RFC 3339 timestamp, then I'd suggest a custom Deserialize trait implementation that parses an RFC 3339 timestamp into a jiff::Timestamp and then converts that to a Zoned using the user's time zone.

[joeydewaal]

For example, in my current implementation, when a user wants to schedule a weekly reoccurring event, they send a start date (RFC 3339) and an amount of weeks it occurs. So this can be 2025-07-18T20:00:00Z and 5, now when calculating the dates these events occur I assume the original date is in Europe/Brussels since that's where most of my users are going to be. Now this is just an assumption and could be wrong.

I guess I just have to find a way to send time zone data to the backend. It's unfortunate that the js Date type doesn't support RFC 8536.

[BurntSushi]

Yeah if you are adding units like weeks, then that duration can change if it covers a DST change. Jiff handles that for you correctly if you use the correct time zone.

But yeah it sounds like you might need to know the user's time zone. Or you can accept the possible inaccuracy and just stick with Timestamp.