`DateTime` equality with different `Offset`s about chrono

[pitdicker]

DateTime compares values as equal if they are the same instant in time, acting as if both values are converted to UTC (which they are internally).

With a DateTime you can always tell if an event is at the same time, or tell the order events, independent of the time zone the DateTime is in.

[jasobrown-rs]

Ahhh, ok. It's making sense to me now. It looks like my code choose the path which "makes things compile", but doesn't create the DateTime instances "correctly". (The comment intended for use cases such as deserializing a DateTime or passing it through FFI makes sense now).

fwiw, I saw a bunch of warnings when upgrading about deprecated functions, like this:

Deprecated since 0.4.27: Use TimeZone::from_utc_datetime() or DateTime::from_naive_utc_and_offset instead

And looks like I picked the less optimial choice (without reading the docs thoroughly). To wrap up, I did try out a more typical (and recommended) path, and the DateTime eqaulity check fails as expected

    let e_date = NaiveDateTime::new(
        NaiveDate::from_ymd_opt(2020, 1, 2).unwrap(),
        NaiveTime::from_hms_milli_opt(3, 4, 5, 660).unwrap(),
    );
    let e = FixedOffset::east_opt(0)
        .unwrap()
        .from_local_datetime(&e_date);
    let f_date = NaiveDateTime::new(
        NaiveDate::from_ymd_opt(2020, 1, 2).unwrap(),
        NaiveTime::from_hms_milli_opt(3, 4, 5, 660).unwrap(),
    );
    let f = FixedOffset::east_opt(18000)
        .unwrap()
        .from_local_datetime(&f_date);
    assert_eq!(e, f);  // fails!

I think I'm good here. Thank you for all the help, @pitdicker

[pitdicker]

from_naive_utc_and_offset is assuming your NaiveDateTimes are in UTC. So the resulting DateTimes are really not describing the same instant in time. You probably want to use TimeZone::from_local_datetime:

    let a = FixedOffset::east_opt(0).unwrap().from_local_datetime(
        NaiveDateTime::new(
            NaiveDate::from_ymd_opt(2020, 1, 2).unwrap(),
            NaiveTime::from_hms_milli_opt(3, 4, 5, 660).unwrap(),
        )
    );

[BurntSushi]

Perhaps I'm misunderstanding here, but if a and b are not the same instant in time, why does assert_eq!(a, b) pass?

[jasobrown-rs]

Yes, @BurntSushi is asking the question more directly :).

[pitdicker]

Sorry, I didn't read closely enough. You are creating two DateTimes from identical NaiveDateTimes, using a method that assumes the value is in UTC.

We have two kinds of methods to construct DateTimes. Some assume the NaiveDateTime is in UTC, some assume it is in local time.

DateTime::from_naive_utc_and_offset assumes the naive value is in UTC (it's in the method name). Also it is not really a method I recommend using. From the documentation:

This is a low-level method, intended for use cases such as deserializing a DateTime or passing it through FFI.`

NaiveDateTime::and_local_timezone and TimeZone::from_local_datetime are two alternatives that assume the naive value is in local time. Both have 'local' in the name.