6 ms·

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 i

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-timedelta-to-add-years https://stackoverflow.com/questions/54394327/using-datetime-...

aiiane 3y ago
What is your definition of "subtracting a year"? Seems like that's a relatively ambiguous operation without more specification.
- kccqzy 3y ago
  Since they mentioned a clean up script, I assume they could easily just use 365 days for that use case.
  - hinkley 3y ago
    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
    - kccqzy 3y ago
      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.
      - hinkley 3y ago
        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.
- Ensorceled 3y ago
  Can you think of any situation where subtracting a year from today's date is ambiguous when today isn't, well, today?
  - aiiane 3y ago
    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.
  - JohnFen 3y ago
    Worth a mention... Falsehoods Programmers Believe About Time: https://news.ycombinator.com/item?id=4128208 https://news.ycombinator.com/item?id=4128208
  - OJFord 3y ago
    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.
    - chatmasta 3y ago
      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.
      - OJFord 3y ago
        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.
- adrianmonk 3y ago
  It is ambiguous, but one part that's pretty unambiguous is that the result should be a date, not a crash.
- ddgflorida 3y ago
  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.
natrius 3y ago
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.
- Swenrekcah 3y ago
  APy should just figure out what I would have wanted to happen
- samatman 3y ago
  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 3y ago
    Which type of year? Sidereal or solar? Did you account for axial precession?
    - samatman 3y ago
      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 3y ago
  > 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"
VirusModulePtr 3y ago
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
LeoPanthera 3y ago
> 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.
- yen223 3y ago
  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.
  - LeoPanthera 3y ago
    relativedelta will do it: from dateutil.relativedelta import relativedelta one_year = relativedelta(years=1)
iooi 3y ago
which is why you should use arrow
cmgriffing 3y ago
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-shift https://arrow.readthedocs.io/en/latest/guide.html#replace-sh...

aiiane 3y ago

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

kccqzy 3y ago
Since they mentioned a clean up script, I assume they could easily just use 365 days for that use case.
- hinkley 3y ago
  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
  - kccqzy 3y ago
    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.
    - hinkley 3y ago
      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.
Ensorceled 3y ago
Can you think of any situation where subtracting a year from today's date is ambiguous when today isn't, well, today?
- aiiane 3y ago
  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.
- JohnFen 3y ago
  Worth a mention... Falsehoods Programmers Believe About Time: https://news.ycombinator.com/item?id=4128208 https://news.ycombinator.com/item?id=4128208
- OJFord 3y ago
  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.
  - chatmasta 3y ago
    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.
    - OJFord 3y ago
      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.
adrianmonk 3y ago
It is ambiguous, but one part that's pretty unambiguous is that the result should be a date, not a crash.
ddgflorida 3y ago
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.

natrius 3y ago

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.

Swenrekcah 3y ago
APy should just figure out what I would have wanted to happen
samatman 3y ago
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 3y ago
  Which type of year? Sidereal or solar? Did you account for axial precession?
  - samatman 3y ago
    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 3y ago
> 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"

VirusModulePtr 3y ago

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

LeoPanthera 3y ago

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

yen223 3y ago
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.
- LeoPanthera 3y ago
  relativedelta will do it: from dateutil.relativedelta import relativedelta one_year = relativedelta(years=1)

iooi 3y ago

which is why you should use arrow

cmgriffing 3y ago

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-shift https://arrow.readthedocs.io/en/latest/guide.html#replace-sh...