Off-by-one-hour error for some far-future dates

[westy92]

PHP's strtotime and WolframAlpha agree that the timestamp 236246216400 is midnight on 05/06/9456 in "America/Chicago" (US Central Time).

However, this code:

let date = Chicago.timestamp_opt(236246216400, 0).single().unwrap();
println!("{:?}", date);

yields "9456-05-05T23:00:00CST", which is an hour earlier than it should be.

However, a later date, 12/31/9456 (from 236266869600), 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.

[pitdicker]

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.

[pitdicker]

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.

[djc]

So this is probably a duplicate then?

[pitdicker]

We have to keep at least one issue open 😄. I think it can be this one for now.