Repository navigation
fix(forge): count elapsed time across DST in DateTimeTool diff - #315
Merged
Eigenwise merged 1 commit intoOct 19, 2026
Merged
Conversation
Two naive inputs both get the same ZoneInfo, and Python subtracts datetimes that share a tzinfo by wall clock, so a diff across a DST change was off by an hour (a day in New York across the spring change was reported as 24 hours instead of 23). Subtract the UTC instants instead.
Eigenwise
approved these changes
Oct 19, 2026
Eigenwise
left a comment
Eigenwise
left a comment
Owner
There was a problem hiding this comment.
Verified with the declared tzdata dependency installed on Windows: the new regression fails on main and all 13 date tool tests pass with the fix. UTC subtraction gives elapsed time across both DST transitions. Thanks.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
diffoperation of the ForgeDateTimeToolis off by an hour whenever a DST change falls between the two inputs, and only when the inputs come without an explicit offset.Both naive inputs get the same
ZoneInfoattached. Python subtracts two datetimes that share a tzinfo by wall clock and ignores their UTC offsets, so the result depends on how the same two instants are written:The first and second lines describe the same two instants, and the real elapsed time is 23 hours. The Brussels day has 25.
The fix converts both values to UTC before subtracting. With it:
I added a test covering both directions of the change; it fails on
main. The tool's tests pass (13), andblack --checkandflake8are clean.