Paul Dicker

Closing this PR for now because realistically there have been enough changes that it is easier to start fresh. #1563 tracks adding a `LocalOffset` type. @esheppa Thank you for your...

We now have a dedicated issue on adding a `CalendarDuration` type with these features: https://github.com/chronotope/chrono/issues/1282.

I updated the test to run with the current version of chrono, 0.4.x. ```rust #[test] fn issue_668() { std::env::set_var("TZ", "Europe/Paris"); let date = NaiveDate::from_ymd_opt(2021, 10, 31).unwrap(); let date_time_1_30 = date.and_hms(1,...

There is no PR, just the comment. Is it worth adding this as a test? Is seems to me like we are not short on tests for timezone transitions.

`parse_from_str` is intentionally forgiving. You can use [`DateTime::parse_from_rfc3339](https://docs.rs/chrono/latest/chrono/struct.DateTime.html#method.parse_from_rfc3339) to get a strict RFC 3339 parser.

Closing in favor of https://github.com/chronotope/chrono/issues/1049. We have non-panicking alternatives to almost all methods now, and making them default for 0.5 is definitely on the roadmap.

Added in https://github.com/chronotope/chrono/pull/1327.

I don't think there is anything we can do here. We just use `std::time::SystemTime::now()`. The standard library checks the return value of `clock_gettime()`, but panics on error. Maybe this should...

Opened https://github.com/rust-lang/rust/issues/115482.

We can even choose to do something different from the standard library. But for now we don't even know when it happens precisely, and if it is worth caring :smile:.