Paul Dicker

I did not realize `%::z` and `%:::z` are fairly recent additions, added in https://github.com/chronotope/chrono/pull/759. Looking at that PR I understand they never properly added to the parser. That seems like...

> I think we should first start to track coverage so we can judge whether this actually improves coverage. @jtmoon79 Do you want to rebase and see what the coverage...

> Is there a way to kick it? Sometimes I would like to 🤣. In this case I think it started counting some of the lines in `mod tests` in...

@jtmoon79 Thank you for you efforts! Unfortunately I don't think these tests add enough value to merge 😞.

My thoughts have changed a bit on this issue. I now think it is best to *shrink* the `Datelike` and `Timelike` traits. They currently offer getter and setter methods. The...

# Error types As a start I'll propose an `Error` enum. The current causes for errors and panics in the parts of the API I have looked add fall in...

# Goals 1. Chrono should allow writing software that handles dates and times correctly and doesn't panic. 2. Chrono should have an API that is pleasant to use. 3. Errors...

# Failure conditions in current/proposed API Okay, this doesn't match the current API completely. And it certainly doesn't guarantee all error conditions I would expect are actually handled correctly. ##...

Based on the API above, I would say that methods that can only fail because of `InvalidParameter` and `OutOfRange` would be best to make panicking by default. For others returning...

@Zomtir We then agree on `from_ymd` . What do you think about for example `NaiveTime::from_hms`? It should only fail if the values come from unvalidated input (`InvalidParameter`). To me that...