Sorry, some clarification: I’m not saying performing the operation is unreasonable, but rather that defaulting to that behavior as the default for performing operations on a “date without time” type is.
This is an example of a “date without time”, but not an example of doing maths using “dates without time”.
Adding a month to a birthday date would be an example of such an operation, but then I’m highly skeptical that returning a date that may be anywhere between 28 to 31 days after the birthday is unambiguously the desired behavior.
Let’s imagine you’re writing a journaling app that works similarly to one of these trending Hobonichi journals, and shows —for each day— what you were doing 1/2/3/4 years ago. This is squarely into the “date without time” territory, and looks like a prime example for using one of the proposed methods:
date.subtract(.year, 1)
But what does the notebook show for Feb 29th? Well, the notebook shows just the leap years, not a duplicated entry for non-leap year’s 28th of February.
A slight variation of the example above would be showing the entry for a month ago. What would a month ago mean in this example? Wouldn’t users find jarring that sometimes the same day is shown for 4 days in a row (March 28/29/30/31 showing the entry for Feb 28th), or that some past days are skipped?
This seems to be a consequence of a “month” being the typical billing period, rather than an intrinsic characteristic of how humans think about dates.
A type that defaults to the Gregorian calendar only, for recent dates only, and with date operations clamped to force alignment with billing periods, seems to be describing a BusinessDate type instead of a “date without time” type.