Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Earliest and latest swapped on DST end when using Local timezone. #1625

Open
AVee opened this issue Nov 7, 2024 · 0 comments
Open

Earliest and latest swapped on DST end when using Local timezone. #1625

AVee opened this issue Nov 7, 2024 · 0 comments

Comments

@AVee
Copy link

AVee commented Nov 7, 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.

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"),
    }
}

(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.

AVee pushed a commit to AVee/chrono that referenced this issue Nov 8, 2024
AVee pushed a commit to AVee/chrono that referenced this issue Nov 8, 2024
AVee pushed a commit to AVee/chrono that referenced this issue Nov 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant