Example Ambiguous offset result?

[vmiklos]

Hi,

I'm not sure if I hold this wrong or if it's a bug, hence asking here instead of filing an issue. :-)

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-rs (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-rs, 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 think this is similar to #413 , but here I don't talk about leap seconds, just the normal DST stuff.)

Thanks.

[jhpratt]

time does not have an assume_timezone method or support for the time zone database in any way. While it certainly sounds like a bug, the bug is in another crate that you're using.

[vmiklos]

Thanks, asked at Yuri6037/time-tz#20 instead.