test_leap_second fails on DST transitition days in the US (and possibly other places).

[plugwash]

I ran into a failure of test_leap_second on the CI test infrastructure, after much racking of brains I figured out what the cause was and was then able to reproduce it using faketime. Specifically with the command "RUST_BACKTRACE=1 TZ=America/New_York faketime 2022-11-06 cargo test"

With current git head of chrono (with the latest stable release the error is slightly different, but I belive the concept is the same).

---- offset::local::tests::test_leap_second stdout ----
    thread 'offset::local::tests::test_leap_second' panicked at 'called `Option::unwrap()` on a `None` value', src/offset/local/mod.rs:238:58
   stack backtrace:
       0: rust_begin_unwind
                 at /usr/src/rustc-1.61.0/library/std/src/panicking.rs:584:5
       1: core::panicking::panic_fmt
                 at /usr/src/rustc-1.61.0/library/core/src/panicking.rs:143:14
       2: core::panicking::panic
                 at /usr/src/rustc-1.61.0/library/core/src/panicking.rs:48:5
       3: core::option::Option<T>::unwrap
                 at /usr/src/rustc-1.61.0/library/core/src/option.rs:755:21
       4: chrono::offset::local::tests::test_leap_second
                 at ./src/offset/local/mod.rs:238:18
       5: chrono::offset::local::tests::test_leap_second::{{closure}}
                 at ./src/offset/local/mod.rs:234:5
       6: core::ops::function::FnOnce::call_once
                 at /usr/src/rustc-1.61.0/library/core/src/ops/function.rs:227:5
       7: core::ops::function::FnOnce::call_once
                 at /usr/src/rustc-1.61.0/library/core/src/ops/function.rs:227:5
    note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.


    failures:
        offset::local::tests::test_leap_second

    test result: FAILED. 162 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 1.21s

The test combines todays date with a leap second local time of 01:02:60, unfortunately being in the middle of the night that time can be either ambiguous or nonexistent on daylight savings transition days causing the test to panic.

[esheppa]

Thanks for the report @plugwash - from my current understanding it looks like we just need to either pick a different time of day to run the test, or more robustly, handle the LocalResult and either bail out of the rest of the test, or add some hours before applying the local time

[jtmoon79]

I was able to reproduce this with this test at tag v0.4.21 and current branch 0.4.x 6655649

    /// Test Issue #866
    #[test]
    fn test_issue_866() {
        #[allow(deprecated)]
        let local_20221106 = Local.ymd(2022, 11, 6);
        let _dt_20221106 = local_20221106 .and_hms_milli_opt(1, 2, 59, 1000).unwrap();
    }

[pitdicker]

Fixed in #1064.