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

Panic at 2017-11-05T01:00:00CDT #15

Closed
benjcal opened this issue Jan 19, 2018 · 1 comment
Closed

Panic at 2017-11-05T01:00:00CDT #15

benjcal opened this issue Jan 19, 2018 · 1 comment

Comments

@benjcal
Copy link

benjcal commented Jan 19, 2018

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
@benjcal
Copy link
Author

benjcal commented Jan 19, 2018

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

@pitdicker pitdicker closed this as not planned Won't fix, can't repro, duplicate, stale Apr 5, 2024
djc added a commit that referenced this issue Apr 15, 2024
Move parse-zoneinfo into workspace
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

2 participants