docs: describe deviations and extensions to the OData spec #56
Conversation
|
|
||
| It's important to note that the final internal value is still expressed in days, | ||
| based on average durations. | ||
| Thus, a month simply represents 30.44 days, while a year represents 365.25 days. |
There was a problem hiding this comment.
Good that this is documented, but I find it unintuitive. What's the practical use of months being 30.44 days and years being 365.25 days?
I would expect things to work like this:
- 2023-01-01 + 1 year = 2024-01-01
- 2024-01-01 + 1 year = 2025-01-01 (even though 2024 is a leap year, so it's 366 days long)
In other words, the duration would only be converted to days when combined with an actual date.
You could argue that this is still ambiguous though.
In Python, timedelta does not support months or years for this reason (I guess), but date.replace does support changing the year or month.
There was a problem hiding this comment.
(For context, this was contributed in #53 by someone external. Can't speak for them of course)
I totally agree, I'm guessing this will mainly be used as a shorthand where accuracy doesn't really matter. E.g. "Give me logs of the past 6 months".
I also agree that the date.replace behaviour would probably be more intuitive. But that would also require us to do the date logic in Python and still converting it to a timedelta before passing it on to whatever backend the user has chosen, since it's infeasible (or straight up impossible) to express that logic on every backend.
ticket: #54