Closed idcollins closed 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.
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.
This is now fixed in release 0.4.2 also available on crates.io.
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()