Serialize DateTime<Tz> not rfc3339 compliant

[jcare44]

There seem to be an issue with the serialize of DateTime<Tz>. Whether it be DateTime<Utc> or DateTime<Local>, serialize seem to always return a string that is compliant with rfc3339 (ending with Z or an offset like +01:00). But with DateTime<Tz>'s serialize, it seem to end (at least in my cases) with the timezone's letters instead (like CEST).

use chrono::{DateTime, Local, Utc};
use chrono_tz::Europe::Paris;
use chrono_tz::Tz;

let d1: DateTime<Utc> = Utc::now();
println!("{}", serde_json::to_string(&d1).unwrap());
// "2023-03-16T10:21:43.519697Z"

let d2: DateTime<Local> = Local::now(); // (My local is also Europe/Paris here)
println!("{}", serde_json::to_string(&d2).unwrap());
// "2023-03-16T11:21:43.520310+01:00"

let d3: DateTime<Tz> = Utc::now().with_timezone(&Paris);
println!("{}", serde_json::to_string(&d3).unwrap());
// "2023-03-16T11:21:43.520494CET"

And it does this even though d3.to_rfc3339() works well.

Did I miss something, or is this a bug?

[djc]

It sure sounds like a bug, though I don't recall the relevant parts of the standards. Would you be able to open a PR to fix this ideally with a bunch of context on what is/isn't allowed in 3339?

[polarathene]

Did I miss something, or is this a bug?

• UTC => Z
• Local => UTC offset aware (_note how you cannot determine the actual IANA timezone for Local from the UTC offset alone_)
• FixedOffset => As implied, a fixed offset regardless of DST rules.
• Tz => Dynamic UTC offset attributed to a specific IANA timezone.

You should find that if you convert the Tz via into() or similar to a:

• DateTime<Utc> it'll now output Z as the offset was stripped away and actual date time info adjusted to accommodate a zero offset (UTC / Z).
• DateTime<Local> will likewise do the same but with respect to your local UTC offset.
• DateTime<FixedOffset> this should now reflect the present UTC offset of the Tz type at the time of conversion, you'll then get that offset displayed with to_rfc3339(). You have to generate this type again with the offset each time you desire it if you want to ensure it's not stale (once crossing the DST boundary introducing a change to the UTC offset).

But yes, RFC 3339 expects to format the IANA TZ to a UTC offset not as the TZ abbreviation (which can be ambiguous, such as with how CST maps to three different UTC offsets).

So that is a bug AFAIK.

---

EDIT: I thought I had reproduced the issue when I chimed in 🤔 If I did I must have had an outdated version of chrono 🤷‍♂️

Reproduction (confirming is fixed):

$ docker run --rm -it --workdir /example rust:alpine ash
# musl-dev needed for compiling with `cargo run`, while tzdata needed for `TZ` ENV support:
$ apk add musl-dev nano tzdata && cargo init

# Replace with above example wrapped in `fn main() { ... }`
$ nano src/main.rs
$ cargo add serde_json chrono-tz chrono --features chrono/serde

# Working:
$ TZ=Europe/Paris cargo run
"2024-04-06T00:23:19.179698686Z"
# This is `+02:00` instead of `+01:00` as April is DST for Paris:
"2024-03-06T02:23:19.179734183+02:00"
"2024-04-06T02:23:19.179776783+02:00"

[pitdicker]

This was fixed in chrono 0.4.27 with https://github.com/chronotope/chrono/pull/1035.