Yuri6037 / time-tz

Implementation of tz database (IANA) for time Rust crate.
BSD 3-Clause "New" or "Revised" License
22 stars 7 forks source link

Daylight Saving Time offsets are ignored #3

Closed idcollins closed 2 years ago

idcollins commented 2 years ago

DST values are not included in the values output by OffsetDateTimeExt::to_timezone and PrimitiveDateTimeExt::to_timezone. For example the code below:

use time::macros::datetime; use time_tz::{timezones, TimeZone, OffsetDateTimeExt}; let london = timezones::db::europe::LONDON; let odt1 = datetime!(2021-01-01 12:0:0 UTC); println!("{:?}", london.get_offset_utc(&odt1)); println!("{}", odt1.to_timezone(london)); let odt2 = datetime!(2021-07-01 12:0:0 UTC); println!("{:?}", london.get_offset_utc(&odt2)); println!("{}", odt2.to_timezone(london));

gives the following output:

TzOffset { timespan: FixedTimespan { utc_offset: 0, dst_offset: 0, name: "GMT" } } 2021-01-01 12:00:00.0 +00:00:00 TzOffset { timespan: FixedTimespan { utc_offset: 0, dst_offset: 3600, name: "BST" } } 2021-07-01 12:00:00.0 +00:00:00

Note that to_timezone gives an offset of zero for both dates even though the TzOffset instances are clearly different. The final line should have an offset of +1 hour.

The source of the problem lies in the impl of Offset::to_utc for TzOffset in timezone_impl.rs. I believe the line:

UtcOffset::from_whole_seconds(self.timespan.utc_offset as i32).unwrap()

should read:

UtcOffset::from_whole_seconds((self.timespan.utc_offset + self.timespan.dst_offset) as i32).unwrap()

Yuri6037 commented 2 years ago

Thanks for the report I'll look into this, I didn't notice this problem when using this crate for bp3d-logger. That clearly looks like a bug.

Yuri6037 commented 2 years ago

I've just looked into this issue and I fixed it for the most part, there's however one strange thing I cam across when adding your example as test case.

Yuri6037 commented 2 years ago

This is now fixed in release 0.4.2 also available on crates.io.