this post was submitted on 22 Jul 2024
78 points (97.6% liked)

Rust

5744 readers
7 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

[email protected]

Credits

  • The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 0 points 1 month ago (10 children)

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+FixedOffset usage required. And no wrong results inevitable.

[–] [email protected] 2 points 1 month ago* (last edited 1 month ago) (9 children)

It’s not built-in support.

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

[–] [email protected] 1 points 1 month ago (8 children)

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.

[–] [email protected] 1 points 1 month ago

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.

load more comments (7 replies)
load more comments (7 replies)
load more comments (7 replies)