chrono-tz
chrono-tz copied to clipboard
Panic at 2017-11-05T01:00:00CDT
Hello,
I find very strange how whenever I try to make a date, whether with Pacific, Central or Eastern (those are the ones I have tried) I get a panic 'invalid time'
Here is my main.rs and the backtrace output.
I already looked in chrono-0.4.0/src/date.rs:78 but I'm not sure if it's a chrono or a chrono_tz issue.
I'd appreciate any pointer or where to look next. Thanks!
main.rs
extern crate chrono;
extern crate chrono_tz;
use self::chrono::prelude::*;
use self::chrono_tz::US::Central;
fn main() {
let time = Central.ymd(2017, 11, 5).and_hms(1, 0, 0);
print!("{:?}", time);
}
backtrace:
thread 'main' panicked at 'invalid time', src/libcore/option.rs:874:4
stack backtrace:
0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
1: std::sys_common::backtrace::_print
at src/libstd/sys_common/backtrace.rs:68
2: std::panicking::default_hook::{{closure}}
at src/libstd/sys_common/backtrace.rs:57
at src/libstd/panicking.rs:381
3: std::panicking::default_hook
at src/libstd/panicking.rs:397
4: std::panicking::begin_panic
at src/libstd/panicking.rs:577
5: std::panicking::begin_panic
at src/libstd/panicking.rs:538
6: std::panicking::try::do_call
at src/libstd/panicking.rs:522
7: std::panicking::try::do_call
at src/libstd/panicking.rs:498
8: <core::ops::range::Range<Idx> as core::fmt::Debug>::fmt
at src/libcore/panicking.rs:71
9: <core::ops::range::Range<Idx> as core::fmt::Debug>::fmt
at src/libcore/option.rs:874
10: <core::option::Option<T>>::expect
at /Users/travis/build/rust-lang/rust/src/libcore/option.rs:302
11: <chrono::date::Date<Tz>>::and_hms
at /Users/benj/.cargo/registry/src/github.com-1ecc6299db9ec823/chrono-0.4.0/src/date.rs:78
12: chrono_tz_crash::main
at src/main.rs:8
13: panic_unwind::dwarf::eh::read_encoded_pointer
at src/libpanic_unwind/lib.rs:101
14: rust_panic
at src/libstd/panicking.rs:459
at src/libstd/panic.rs:365
at src/libstd/rt.rs:58
15: chrono_tz_crash::main
I now realize that Nov 5 2017 was the daylight saving day so, seems like 01:00:00 never existed?
Knowing this I'll do more tests. Maybe there's a better way to address this specific kinds of errors instead of just panic with invalid time