Repository navigation
Read Freetrade dates in UK time - #1010
Merged
Merged
Conversation
The Freetrade export timestamps every transaction in UTC, and the parser took the calendar date straight from that instant. The tax year boundary and the same-day and 30-day matching rules run on UK calendar days, and 5 April always falls inside BST, so anything stamped after 23:00 UTC on 5 April was filed in the previous tax year. Convert to Europe/London before taking the date, the same way Trading 212 does since cgt-calc#1000. A zone-less timestamp is read as UTC rather than as the machine's local time, so the parsed date does not depend on where the calculation is run. Document the behaviour on the Freetrade page. The date-only exports (Schwab, Interactive Brokers, Hargreaves Lansdown, Vanguard, Morgan Stanley, Sharesight and RAW) carry no time to convert, so say so once on the brokers index rather than on each page.
|
📖 Docs preview: https://pr-1010.cgt-calc.pages.dev Built from e63ee89 · updated 2026-08-26 14:10 BST |
hdimer
marked this pull request as ready for review
August 25, 2026 23:23
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1010 +/- ##
=======================================
Coverage 94.10% 94.10%
=======================================
Files 37 37
Lines 4902 4906 +4
Branches 810 811 +1
=======================================
+ Hits 4613 4617 +4
Misses 150 150
Partials 139 139
Flags with carried forward coverage won't be shown. Click here to find out more.
|
Collaborator
|
Thanks! |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
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.
Fixes #1005.
FreetradeTransaction.__init__took the calendar date straight from the UTC timestamp, so a transaction stamped after 23:00 UTC on 5 April was filed in the previous tax year, and the same instant could also land on the wrong side of same-day and 30-day matching.It now converts to
UK_TIMEZONEbefore taking the date, the same wayTrading212Transactionhas since #1000. As there, a zone-less timestamp is read as UTC rather than as the machine's local time: every export carriesZ, but without that the parsed date would depend on the reader's clock, andBASE_ROW_VALUESin the Freetrade tests uses the zone-less shorthand.The new parametrized test mirrors the Trading 212 one: the 5/6 April boundary (22:59:59 UTC still 5 April, 23:00:00 and 23:30:00 already 6 April, the last of those zone-less), the evening after the clocks go back in October, and two winter dates where UK and UTC agree anyway. I checked each case discriminates by re-running it against the unfixed parser (two boundary cases fail), against a plain
astimezonewith no zone-less handling underTZ=Pacific/Auckland(the zone-less case fails), and against a crude "add an hour from April to October" version (the October case fails).The second half of the issue is documented rather than fixed.
docs/brokers/freetrade.mdgains a "Dates and time zones" section mirroring the Trading 212 one, anddocs/brokers/index.mdsays once that every other export states a date with no time, so cgt-calc reads it as the broker wrote it. That seemed better than repeating the same paragraph on six broker pages, but happy to move it if you would rather each page carried it.Checks:
uv run pytest904 passed, and the Freetrade tests also pass underTZset to UTC, Auckland, Los Angeles and Tokyo. Plus ruff format, ruff check, mypy, ty, dprint, codespell and Harper.Disclosure: written with AI assistance (Claude). The bug was reproduced against
mainfirst, and the new test was confirmed to fail on the unfixed parser before anything was changed.