Paul Dicker

We are now at 0.4.26, this can be closed?

We have multiple issues that track the issues out formatting code can panic. I'm closing this one since the `Date` type is deprecated. #1127 is the best issue to watch.

I agree the docs should say something about the issue with reading the `TZ` environment variable and our history with RUSTSEC-2020-0159. But since it is fixed with https://github.com/chronotope/chrono/pull/677 we should...

If we would add a `Default` variant to `Pad` that would mean we have to learn the formatting and parsing code what the defaults for all possible formatting fields are....

> Postponing the failures of parsing from the parsing stage to the formatting stage doesn't sound like a great option, in particular a reasonable approach is to use a long-lived...

I have arrived at an API that seems to do everything I want. ### Part 1: format string parsing Add two new fallible methods to `StrftimeItems`: `parse` and `parse_into_slice`. ```rust...

Some things I have looked at related to creating a new formatting API: #### Are parsing errors in a format string and unavailable fields on the input type the only...

Found one more interesting issue while reviewing https://github.com/chronotope/chrono/pull/1058: not all locales have a 12-hour clock. In that case the local format string for `%r` is `""` instead of something like...

@kamadorueda You write clearer then I do, good summary. > 3\. Some directives can only represent a subset of what the timestamp allows > (e.g. RFC3339 year is 0..=9999, but...

The solution I have gone with in https://github.com/chronotope/chrono/pull/1196 was to add `From` impls: https://github.com/chronotope/chrono/pull/1196/commits/caf2b554cb2045e99336694b98dc972d21127dda, as that adds the smallest API surface. But I am not married to the details :smile:.