How to identify if a generic DateTime<Tz> is in a DST transition?

[davidhewitt]

Looking into PyO3/pyo3#3266, I hit a stumbling point regarding DST transitions.

For NativeDateTime::and_local_timezone a LocalResult is returned to handle the case where the naive local datetime might be ambiguous or not present in the corresponding timezone.

What about going the other way? If I have DateTime<Tz> for some generic Tz: TimeZone, what's the recommended way to identify if this tz-aware datetime represents an ambiguous local timezone? I think I can do something like:

let is_dst_folded = match dt.naive_local().and_local_offset(dt.offset) {
    LocalResult::None => unreachable!(),
    LocalResult::Single(_) => false,
    LocalResult::Ambiguous(_, folded) => dt == folded
};

... but that seems quite a roundabout way of doing it, so I was wondering if you thought there was anything better?

[pitdicker]

That is mostly it. However, LocalResult::Ambiguous is only returned if a transition creates a fold (clock is moved backward), and LocalResult::None when the transition crates a gap (clock is moved forward).

The shortest way to write this is using LocalResult::single():

let is_dst_folded = dt.naive_local().and_local_offset(dt.offset).single().is_none();

Note that we sometimes rely on platform functions to convert to DateTime<Local>. On Windows and wasm the platform function always returns a single value, so we can't return anything but LocalResult::Single there yet.

And also unfortunately an error in the platform function makes us return LocalResult::None, just like during a transition gap :-(. But if you use something like chrono_tz which is fully under our control, this method works.

[davidhewitt]

Thanks for the confirmation. 👍