-
-
Notifications
You must be signed in to change notification settings - Fork 663
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
incorrect time difference for times before and after DST switch #1136
Comments
Hi! I'm interested in working on this bug. |
If this gets addressed, it would also make sense to change the shift function to account for DST changes. Its hard to say which approach is 'correct', but I think accounting for DST is more natural and would result in fewer errors in code that uses arrow. The current shift behavior ignores DST change on the resulting time:
Since t1 is not DST and t2 is within DST (clock has move forward), adding 12 hours to t1 would result in a wall-clock time that is 13 hours ahead. Meaning t2 would be <Arrow [2023-03-12T10:00:00-07:00]> Either approach might confuse someone, but given that a reason to use arrow is timezone awareness (and a big part of most timezones is DST) I'd prefer both DST aware math operations and more DST aware shift. |
Issue Description
The time difference between two localized times isn't the actual difference in seconds, but rather the naive difference.
Example:
results in:
would expect 1.0 instead.
Workaround use timestamp() instead:
results in:
System Info
The text was updated successfully, but these errors were encountered: