Extract any Python datetime into some chrono type with abi3 feature enabled

[124C41p]

Hi everyone. First of all, I highly appreciate that version 0.21 allows me to extract Python datetimes into Rust chrono types even if some abi3 feature is enabled! I needed ugly workarounds before...

If I am not mistaken however, there seems to be no single chrono type which can be extracted from every Python datetime. For example, obj.extract::<DateTime<FixedOffset>> fails for datetime.now(), obj.extract::<NaiveDateTime> fails for datetime.now(timezone.utc), etc.

In order to get any Python datetime into the Rust world, I am currently using this helper function:

fn extract_dt(obj: &Bound<PyAny>) -> Option<DateTime<Utc>> {
    if let Ok(dt) = obj.extract::<DateTime<FixedOffset>>() {
        return Some(dt.to_utc());
    }

    if let Ok(dt) = obj.extract::<NaiveDateTime>() {
        return Some(dt.and_local_timezone(Local).single()?.to_utc());
    }

    None
}

Is this what I am supposed to do or is there an easier way? Is my helper function correct, and does it actually work for any possible Python datetime object?

[davidhewitt]

Hello, good question.

I think the problem with automatic conversion of naive to timezone-aware date times is that it's quite common for users to not think hard about what their naive datetime means. I think you're right in the code above that it's now typically treated as local but it feels like this is still a space where it's easy to introduce a footgun.

The code you wrote above looks correct. You could package this up into a newtype and implement FromPyObject for that type (or use #[pyo3(from_py_with = "extract_dt")] to avoid needing to take &Bound<'_, PyAny> as your function argument.

[124C41p]

Hi, thanks for pointing that out! You are right that it is probably better to be explicit about assigning a timezone to a naive DateTime. For still being able to extract any Python DateTime to a Rust type, I would introduce an enum like this:

pub enum AnyDateTime {
    Naive(NaiveDateTime),
    OffsetAware(DateTime<FixedOffset>),
}

As this is just a simple wrapper, it is trivial to implement the FromPyObject / ToPyObject traits. I think it might become quite handy to users if it implements all functions which NaiveDateTime and DateTime have in common. For example, it could trivially implement the chrono Datelike and Timelike traits as well as some conversion methods:

impl AnyDateTime {
    /// Naive date times are considered to be in timezone `default_tz`.
    /// Returns `None` if a underlying naive time falls in a fold or gap in `default_tz`
    pub fn with_timezone<T: TimeZone>(
        &self,
        target_tz: &T,
        default_tz: impl TimeZone,
    ) -> Option<DateTime<T>> {
        match self {
            Self::Naive(dt) => Some(
                dt.and_local_timezone(default_tz)
                    .single()?
                    .with_timezone(target_tz),
            ),
            Self::OffsetAware(dt) => Some(dt.with_timezone(target_tz)),
        }
    }

    pub fn to_utc(&self, default_tz: impl TimeZone) -> Option<DateTime<Utc>> {
        self.with_timezone(&Utc, default_tz)
    }
}

Do you like to have something like this in PyO3 (I could start a PR then)? Or is it more suitable for a separate crate, or rather unnecessary?

[davidhewitt]

Agreed that what you propose looks like the right design. I think given my concern that this makes it easy for unsuspecting users to make timezone mistakes, I would prefer not to have it in PyO3 for now. Perhaps other PyO3 maintainers think differently though!

It definitely looks general enough that it would likely have value published as a crate, and perhaps if it proves very popular we could support it in PyO3 in the future.