Example Ambiguous offset result?

[vmiklos]

I'm not sure if I hold this wrong or if it's a bug, but looks like discussions are disabled, hence asking here :-)

I'm writing a small ics2txt tool at https://github.com/vmiklos/vmexam/tree/master/ics2txt, and checking what code is not covered by tests. One edge case is when assume_timezone() doesn't return Some, i.e. a case where a local time doesn't have a single timezone, but has 0 or 2.

I tested this with the Europe/Budapest timezone, where I know it's the usual European case, i.e. clocks are adjusted in a way that the offset is incremented by 1h on the last weekend of March, on Sun, from 2:00 to 3:00. I would assume this means that the result here for 2:30 local time on that night should be None. However, when I test this, here is what I get:

Sun, 31 Mar 2024 02:29:00 is +0000
Sun, 31 Mar 2024 00:29:00 is +0100
Sun, 31 Mar 2024 06:29:00 is +0200

I.e. the "before 2h" and "after 3h" case works as expected, but that +0000 offset is odd, I expect an error instead of a zero offset.

Is this a bug in time-tz (or one of its dependencies) or is a bug in the tzdata database that I have on Linux?

If it's not a bug in time-tz, is there any real-world example on how to trigger the OffsetResult::Ambiguous and OffsetResult::None cases when one calls assume_timezone() on a PrimitiveDateTime?

(I originally asked this at time-rs/time#646, but turns out that the impl for this trait is in this crate.)

Thanks.

[Yuri6037]

I'm not sure if I hold this wrong or if it's a bug, but looks like discussions are disabled, hence asking here :-)

What do you mean by "discussions"? I didn't even know that existed on GitHub... Could you tell me how to enable it?

I'm writing a small ics2txt tool at https://github.com/vmiklos/vmexam/tree/master/ics2txt, and checking what code is not covered by tests. One edge case is when assume_timezone() doesn't return Some, i.e. a case where a local time doesn't have a single timezone, but has 0 or 2.

I tested this with the Europe/Budapest timezone, where I know it's the usual European case, i.e. clocks are adjusted in a way that the offset is incremented by 1h on the last weekend of March, on Sun, from 2:00 to 3:00. I would assume this means that the result here for 2:30 local time on that night should be None. However, when I test this, here is what I get:

Sun, 31 Mar 2024 02:29:00 is +0000
Sun, 31 Mar 2024 00:29:00 is +0100
Sun, 31 Mar 2024 06:29:00 is +0200

I.e. the "before 2h" and "after 3h" case works as expected, but that +0000 offset is odd, I expect an error instead of a zero offset.

Is this a bug in time-tz (or one of its dependencies) or is a bug in the tzdata database that I have on Linux?

This can't be a bug with your system tzdata database as the tzdata database is baked into the crate from the official distribution on GitHub.

If it's not a bug in time-tz, is there any real-world example on how to trigger the OffsetResult::Ambiguous and OffsetResult::None cases when one calls assume_timezone() on a PrimitiveDateTime?

I'm not sure what you mean because I can't reproduce this issue on my local machine. Could you post a minimal reproducible test case on this issue? This is what I tried on my local machine which works.

    #[test]
    fn errors() {
        let datetime = datetime!(2024-03-31 02:30:00).assume_timezone(timezones::db::europe::BUDAPEST);
        assert!(datetime.is_none());
        let datetime = datetime!(2024-03-31 02:29:00).assume_timezone(timezones::db::europe::BUDAPEST);
        assert!(datetime.is_none());
    }

[vmiklos]

What do you mean by "discussions"? I didn't even know that existed on GitHub... Could you tell me how to enable it?

See the screenshots here: https://docs.github.com/en/discussions/quickstart

This can't be a bug with your system tzdata database as the tzdata database is baked into the crate from the official distribution on GitHub.

Ah, great to know, I didn't realize that.

I'm not sure what you mean because I can't reproduce this issue on my local machine. Could you post a minimal reproducible test case on this issue? This is what I tried on my local machine which works.

    #[test]
    fn errors() {
        let datetime = datetime!(2024-03-31 02:30:00).assume_timezone(timezones::db::europe::BUDAPEST);
        assert!(datetime.is_none());
        let datetime = datetime!(2024-03-31 02:29:00).assume_timezone(timezones::db::europe::BUDAPEST);
        assert!(datetime.is_none());
    }

Thanks! that test passes here as well, I can works backwards from there. My "test" was just some manually constructed ical file that tried to do the same (with the above linked ics2txt tool), and I was confused if my API usage is wrong or not. But then this will be something on my end. :-)