I don't know the specifics of this implementation, but if YearMonth is what it sounds like - an object representing a specific month in a specific year and nothing more granular than that, then I'm all for it. Some examples of where I've used such constructs in the past (often having to hackily implement them myself on top of native datetime libs):

- data processing and graphing: a lot of data is collected on a monthly basis and represents the aggregate for that month (like monthly energy use). Naively storing it as a full date and ignoring the day means that you now have a compatibility issue with other data, collected monthly, that isn't aggregate (like the height of a tree) - "[THING] of the month": something is chosen by a community poll or admin or however else to be highlighted for/of that month You need something to use as a key for it and a YearMonth captures the requirements perfectly. Especially when you then have to display a localised title above it, having it be a distinct class and not just a full date will save you a lot of trouble. - same as above, but a more business-y use case: various monthly reports. Usually created in the next month, you need a way to represent which month it's "for"

I should clarify that my dislike of YearMonth and ilks is for standard types without any localization [1] or non-Gregorian support. They do crop up from time to time but you have a very straightforward representation of YearMonth in any reasonable language: a pair of (year, month), essentially interpreted as a mixed-radix number. Date and general date-time components are not that simple (thanks to the calendar system itself, leap seconds and time zones) and deserves separate types.

[1] I firmly believe that the localization support is too large for standard libraries. In particular, that "localization support" usually means that you have a ripoff version of CLDR & ICU interface and no equivalent to something like gettext, essential to any actual localization task.