[natrius]

It's not that python doesn't have a clean way to subtract a year, it's that "subtract a year" is imprecise. There's a clean way to subtract 365 days, and there's a clean way to set the year one year earlier. But if you're doing the second thing, is python supposed to silently change to March 1 when you change the year from a leap day? There's no way around handling edge cases.

[samatman]

This has been a factor in contract law for longer than computers have existed. "Subtract a year" or "Add a year" aren't really imprecise, it's just that there are two ways you can interpret it: 365 days, or 12 months. When adding, you get the same result: end of February, the 28th. Subtracting, you get one of March 1st for 365 days and February 28th for 12 months.

Most jurisdictions use the 12 month standard, fwiw. I believe that's the ISO ruling as well, but I wasn't able to confirm that.

[emmelaich]

Which type of year? Sidereal or solar? Did you account for axial precession?

[samatman]

To be a bit blunt, these questions are entirely irrelevant, since you know the answer as well as I do: the calendar year, the one Western law and international business uses uniformly. It's very clever of you to mention that other concepts of the year exist. Kind of. Would have been more clever if you'd realized that they aren't germane, any more than the Islamic, Jewish, Indian, or Chinese years are.

[bhaney]

> There's a clean way to subtract 365 days

What is it? Does it attempt to return a datetime that's the same time as the input but 365 calendar days earlier (ignoring leap seconds? compensating for time zone changes?), or does it subtract 31536000 seconds from the current datetime? Because those aren't necessarily the same and it's ambiguous which one you mean by "subtract 365 days"

[Swenrekcah]

APy should just figure out what I would have wanted to happen