-
Notifications
You must be signed in to change notification settings - Fork 522
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DateTime::years_since
is tricky during ambiguous local time
#1398
Comments
We can get a sensible result if we create an intermediate value with the date of |
I have questions:
|
I was just reading the implementation of Turns out it works in local time (sensible). The method signature requires the timezone to be the same. That only leaves the case of the offset from UTC changing within the same timezone as a potentially tricky case.
Because of a DST transition on that day, and we don't pick any side but naively use the local time.
No. It is used nowhere, we don't even seem to have tests. Actually I was in the process of deprecating it but couldn't come up with a usable alternative.
I suppose from the moment month, day and time are equal it counts as a full year that has passed. If the clock turns backwards after that it should keep counting that full year. Should we care about this issue? |
It's probably worth fixing but also not very high priority? Could do something like comparing the months and if the difference is larger than 1 return, same for months and days, then convert both to |
I can probably write the fix described in #1398 (comment) and a test in two hours. The reason to open this issue is that I should get in the habit of making notes such as this public instead of keeping a single line somewhere on my PC with 'TODO'. It seemed low priority enough for me to not work on directly and discuss in a PR 🤣. |
Suppose the clock is turned back on say 2024-03-31 from 3:00 to 2:00 due to DST. We want to compare the current time with 2023-03-31 at 2:30:
The current behavior is that on 2024-03-31 it will return 0 years until 2:30. From the first 2:30 until 3:00 it will return 1 year as result. From the second 2:00 until 2:30 it will return 0 years. And after that 1 year again.
I am not sure what the 'right' result should be, but going back and forth seems not to be it.
The text was updated successfully, but these errors were encountered: