Paul Dicker

> First, regarding new constants, bringing in constants related to newly introduced API functions is low-effort, low-risk, low maintenance, and just darn useful for users. I am not so sure...

> I'm not sure about today as it introduces the contextual oddity of which timezone the system reports... but it is convenient. 🤔 Forgot about this one. We used to...

### NaiveDate::end_of_month Last summer I was writing a fast, compactly encoded alternative to [chrono_tz](https://crates.io/crates/chrono-tz) (not finished sadly). And 'last day of the month' or 'last x weekday of the month`...

I was not even at the point yet to have a wishlist :smile:. Basically just thinking out loud. Three seem useful to me: `NaiveDate::end_of_month`, `NaiveDate::MAX_YEAR` and `NaiveDate::MIN_YEAR`. A few others...

Then we seem to have an answer for @danwilliams. > * I see a lot of value in the "full" functions for `Duration`, which provide constructors and getters for using...

> > @pitdicker: Chrono could use some more help, and you seem to be willing to contribute. Do you want to dive into some of the open PRs or issues?...

> Pff, we just had a bunch of issues reported by users who were depending on the exact value of some of the limit constants, which I think goes to...

@danwilliams Are you still interested in working on some of these additions?

Yes, this is https://github.com/chronotope/chrono/pull/1317. @djc I'd like edit the release notes to put the changes into sections like changed, fixed etc, and call out these changes to the accepted range...

Updated the release notes https://github.com/chronotope/chrono/releases/tag/v0.4.32.