Hacker News Reader

Comment by rlaager | Hacker News Reader

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 easy enough to address. There are various StackOverflow posts on such things. Here is one: https://stackoverflow.com/questions/54394327/using-datetime-...

View on HN

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.

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

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.

> 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"

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

What is your definition of "subtracting a year"? Seems like that's a relatively ambiguous operation without more specification.

Can you think of any situation where subtracting a year from today's date is ambiguous when today isn't, well, today?

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.

Worth a mention... Falsehoods Programmers Believe About Time: https://news.ycombinator.com/item?id=4128208

Since they mentioned a clean up script, I assume they could easily just use 365 days for that use case.

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

It's a cleanup script. I bet nobody cares it's off by one day. Also I doubt a cleanup script has a charting function.

Everything is use case dependent. Sometimes the use case is unimportant enough that mistakes are okay.

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.

It is ambiguous, but one part that's pretty unambiguous is that the result should be a date, not a crash.

> now.replace(year=now.year-1)

Yeah but this is bad code. Python certainly does have a "clean" way to subtract a year, you subtract a datetime.timedelta object.

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.

relativedelta will do it:

  from dateutil.relativedelta import relativedelta
  one_year = relativedelta(years=1)

I get it if you don't want to bring in another dependency, but Arrow has a lot of nice utility methods: https://arrow.readthedocs.io/en/latest/guide.html#replace-sh...

which is why you should use arrow

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

Reply on news.ycombinator.com