Open westy92 opened 11 months ago
Interesting! I have no idea yet...
Some more example code:
use chrono::{FixedOffset, Offset, TimeZone};
use chrono_tz::America::Chicago;
fn main() {
let date1 = Chicago.timestamp_opt(236246216400, 0).single().unwrap();
println!("{:?} {}", date1, date1.offset().fix());
let date2 = Chicago.timestamp_opt(236266869600, 0).single().unwrap();
println!("{:?} {}", date2, date2.offset().fix());
let dst_offset = FixedOffset::east_opt(-5 * 60 * 60).unwrap();
let date3 = date1.with_timezone(&dst_offset);
println!("{:?} {}", date3, date3.offset().fix());
assert_eq!((date2 - date1).num_hours(), 239*24 + 1);
}
Output:
9456-05-05T23:00:00CST -06:00
9456-12-31T00:00:00CST -06:00
9456-05-06T00:00:00-05:00 -05:00
It seems we forget DST somewhere.
So the problem here is that chrono-tz only includes data for a fixed set of years, with the end of this century as the limit. We should at least document that limitation.
So this is probably a duplicate then?
We have to keep at least one issue open :smile:. I think it can be this one for now.
PHP's strtotime and WolframAlpha agree that the timestamp
236246216400
is midnight on05/06/9456
in"America/Chicago"
(US Central Time).However, this code:
yields
"9456-05-05T23:00:00CST"
, which is an hour earlier than it should be.However, a later date,
12/31/9456
(from236266869600
), works correctly.Is the issue that the date is too far in the future? PHP's strtotime is using the same IANA TZDB under the hood.