1. Support for partials

================

[....]

We tried to think of a use case but couldn't think of any.

When you are using a calendar year for fiscal purposes (in Brazil, its January-December), you could use MonthDay to represent a point in time separately from the year. If a MonthDay represents a holiday, there might be other use cases related to the current year.

That being said, it does not cost us anything to have it for consistency.

Consistency for me is a good argument in itself. If we couldn't think of the use case, maybe it's just because we're temporarily blind. Being consistent doesn't hurt, especially given the effort is minimum :-)

2. Resolution
==========
[...]

This would truncate the LocalDates to ChronoUnit.MONTHS before doing the comparison, ensuring that the date should be at least next month.

While this is a valid use case, it seems a little bit specific to me in the sense you have a reference for "now" as a comparison (a use case I mentioned before is validating a temporal object against an arbitrary reference) and in this case converting it. This also limits the "truncation" (which is just a specific case of conversion) to ChronoUnit, when other types of conversion might be needed.

 

3. orPresent

=========
[...]

Personally, I prefer having one annotation with an option rather than 2 different annotations - I think it has a better semantic - but I can see the rationale behind Gunnar's proposal.

I vote for one annotation.