One cleanup script broke because Python doesn’t have a clean way to subtract a year, and if you do now.replace(year=now.year-1), you get a ValueError when now is 2/29.
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.
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.
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.
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"
Yes - on any day, subtracting a year might mean subtracting the average length of a year (which is a bit more than 365 days), or wanting the same day and month number in the previous calendar year, or wanting the same semantic difference ("last Monday of the month in January"), to name a few possible meanings.
Moving bank/festive holidays, first Monday of the year(, first work day of the year not Monday if that's NYD and bank holiday), lunar occasions.
'subtract a year' is imprecise and has many meanings, if what you want is 'same day, same month, previous year' then say that and do that, that's conceptually `date.year -= 1` not `date -= 1 year`, and will have this bug.
You could subtract 365.25 days, but then you're left with a new problem: just because you can amortize a leap day over four years doesn't mean that you get an extra 6 hours each year.
And as I just learnt elsewhere in this thread, it would actually be three four-hundredths less than that anyway, i.e. 365.2425, since only one in four centenaries is a leap year.
But then it'll be off by one day for the rest of this year. And someone will notice that they no longer have March 1 2023-March 1 2024 in their chart, but March 2 2023
While that's true, I'm sharing scar tissue here not hypotheticals.
There's often someone out there who interprets such things as a 3 month, or 1 year retention policy and that it means they're entitled to look at the entire range whenever they want.
Plenty of thought has gone into this. Look at what database date functions do when you ask it to subtract 1 year. I will agree that there is not one answer.
timedelta doesn't take "years" as a parameter, for the reasons others have listed here. It's ambiguous what subtracting by a year means, and there's no real sensible default either.
Okay I am having really odd undefined behavior in Python in UART communications that were working just fine yesterday... My boss joked it could be a leap year thing but at this point it wouldn't surprise me. Switch over to using Rust and no issues at all
It’s easy enough to address. There are various StackOverflow posts on such things. Here is one: https://stackoverflow.com/questions/54394327/using-datetime-...