Paul Dicker

# Parsing errors Current error enum for parsing errors: ```rust pub enum ParseErrorKind { /// Given field is out of permitted range. OutOfRange, /// There is no possible date and...

My knowledge of error handling in Rust is a couple of years out of date. But as I understand it error chaining remains unavailable without the standard library or `alloc`....

> I took a tour around that issue and kept the existing logic without much afterthought. That was very reasonable to explore were and how the API should change. And...

### Making the error implementation private? One option is to wrap the error enum inside a newtype `pub struct ChronoError(ChronoErrorKind)`, and use a method `kind()` to get to the enum....

The initial PR to add an error type is up https://github.com/chronotope/chrono/issues/1049! # Parsing errors I've started working on converting the parsing code to the new `Error` type. I now think...

> It's not immediately obvious that this function can panic, but it can, because `DateTime` implements `From` in a way that panics on overflow. If the `SystemTime` comes from an...

It seems good to write down some of the steps I am planning. ### `TimeDelta` type - [x] A couple of uses of `TimeDelta` constructors do range checks because they...

This issue seems to have mostly served its purpose. There is still some iteration on the details, so the end result is going to be different from what is discussed...

I am trying to figure out what is the least hacky way to prevent panics for `DateTime`s near the end of the range of `NaiveDateTime`. Everything that uses `DateTime::naive_local` can...

I think a lot of this is fixable. - It would be easiest if we can make the range of acceptable values of `NaiveDateTime` 24 hours smaller on the min...