You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When converting a NaiveDateTime that is on the end of DST into one in the Local timezone we get an Ambiguous result that contains the two possible results in the wrong order. Instead of (earliest, latest) the result contains (latest, earliest) .
See the code below for a reproduction.
use std::env;
use chrono::{DateTime, Local, MappedLocalTime, NaiveDate, NaiveDateTime, NaiveTime, TimeZone, Utc};
fn main() {
// Set Posix Timezone CET/CEST (as found in /usr/share/zoneinfo/CET).
// DST ends last sunday of october at 03:00 moving back to 02:00
// We set the TZ var here, but the same error occurs without any special settings on a linux system in Europe/Amsterdam
env::set_var("TZ", "CET-1CEST,M3.5.0,M10.5.0/3");
let date = NaiveDateTime::new(NaiveDate::from_ymd_opt(2024, 10, 27).unwrap(), NaiveTime::from_hms_opt(2, 0, 0).unwrap());
let mapped_date = Local.from_local_datetime(&date);
match mapped_date {
MappedLocalTime::<DateTime<Local>>::Ambiguous(early, late) => {
println!("Early before late: {}", early < late);
println!("Early after late: {}", early > late);
assert_eq!(early, Utc.with_ymd_and_hms(2024, 10, 27, 0, 0, 0).unwrap());
assert_eq!(late, Utc.with_ymd_and_hms(2024, 10, 27, 1, 0, 0).unwrap());
},
MappedLocalTime::<DateTime<Local>>::Single(_) => assert!(false, "Expected ambiguous date"),
MappedLocalTime::<DateTime<Local>>::None => assert!(false, "Expected ambiguous date"),
}
}
So far I've seen this happen Linux when using default zone info from the system (set to Europe/Amsterdam) and on an ESP32 when setting the TZ environment variable. I haven't had the change to check the behavior on Windows yet. This bug doesn't seem to exist on Windows.
It also doesn't seem to fail when using zones from chrono_tz or tzfile.
The text was updated successfully, but these errors were encountered:
AVee
pushed a commit
to AVee/chrono
that referenced
this issue
Nov 8, 2024
When converting a NaiveDateTime that is on the end of DST into one in the Local timezone we get an Ambiguous result that contains the two possible results in the wrong order. Instead of (earliest, latest) the result contains (latest, earliest) .
See the code below for a reproduction.
(playground)
So far I've seen this happen Linux when using default zone info from the system (set to Europe/Amsterdam) and on an ESP32 when setting the TZ environment variable.
I haven't had the change to check the behavior on Windows yet.This bug doesn't seem to exist on Windows.It also doesn't seem to fail when using zones from chrono_tz or tzfile.
The text was updated successfully, but these errors were encountered: