CSV files exported from different exchanges use at least three different time formats. Binance uses UTC+0, OKX annual statements default to UTC+8, and some exchanges use the local time zone you selected when signing up.
If you drag all three CSVs directly into the same reporting tool, the same transaction recorded on different platforms could be off by 8 hours. Cost matching, holding periods, and cross‑platform transfer matching will all break because of this time gap.
Step 1: Identify the Time Source in Each CSV
How to do it: Open every CSV file downloaded from an exchange and look at the time column's field name and value format.
Case A: Binance
Spot trading CSVs usually have a column named
UTC_Time, with values like2024-01-01 12:00:00.Binance's official documentation clearly states that history is shown in UTC+0.
Case B: OKX
Annual statements and similar reports default to UTC+8.
Settlement cycles for features like copy trading also use UTC+8.
Case C: Other exchanges (Bybit, Gate, MEXC, etc.)
Some platforms let you choose a time zone in account settings, and the exported CSV uses that time.
Some platforms use UTC but label the column simply
TimeorDate, without mentioning UTC.
Completion standard: You can state exactly which time zone each CSV file in your hand uses, instead of assuming they are all the same.
Step 2: Convert All Timestamps to UTC
How to do it:
Case A: Already in UTC (e.g., Binance) — No changes needed.
Case B: Fixed offset like UTC+8 (e.g., OKX annual statement):
In Excel, add a new column and subtract the offset with a formula. For UTC+8, subtract 8 hours; for UTC+0, keep as is.
Note: This method is only safe for regions without daylight saving time. UTC+8 does not observe daylight saving, so a fixed offset is safe.
Case C: Uncertain time zone (many small‑exchange CSVs):
When importing into tools like Koinly, do not select "Auto‑detect" in the time zone dropdown. Manually choose the time zone the file actually uses—the tool will convert to UTC in the background.
Open‑source tools like Rotki are adding "specify time zone on import" features. The key is to use IANA time zone names instead of fixed offsets, because daylight saving offsets can change.
Completion standard: Every transaction time across all your CSVs has been converted to UTC before merging. OKX UTC+8 records have been shifted back by 8 hours, now in the same time system as Binance records.
Step 3: Set the "Output Time Zone" in Your Reporting Tool (Do Not Change the Data)
How to do it: Import the unified UTC data into your reporting tool, then choose your desired "report output time zone" in the tool's settings.
Koinly lets you set the time zone in Settings. The capital gains reports and tax reports it generates will assign transactions to the correct tax year based on your chosen zone, preventing cross‑year transactions from landing in the wrong tax year.
CoinTracking also supports setting an account time zone, but this only affects report output—it does not change the underlying stored data.
Completion standard: Your reporting tool stores data uniformly in UTC, but the final exported tax report assigns years according to your local time zone.
Step 4: Verify Cross‑Platform Transfer Matching (The Direct Consequence of Time Zone Errors)
How to do it: Pick a transfer you made from Platform A to Platform B:
Find the withdrawal record in Platform A's CSV (after converting to UTC).
Find the deposit record in Platform B's CSV (after converting to UTC).
The two timestamps should be close (usually within a few minutes). If they differ by several hours, one side's time zone has not been converted correctly.
Common cause of failure: Many people merge CSVs without converting time zones first. The withdrawal and deposit records then show an 8‑hour gap. Third‑party tools fail to match them and treat the same funds as two separate records — "withdrawal + new buy" — breaking the cost‑basis chain.
Risk reminder: If your transaction happens near midnight UTC, an uncorrected time zone will push the trade into the previous tax year on the report. Under FCA regulatory standards, all reportable event clocks must be synchronized to UTC. If your reporting tool does not store everything in UTC, year‑end reconciliation will suffer from incorrect tax‑year assignment.
How to Verify Your Fix Worked
Find a transaction that occurred between 23:00 and 24:00 UTC. Confirm that its timestamp in your tool's "transaction list" is shown in UTC time. If yes, the data layer is correct. Then export the annual tax report once more and make sure that transaction is assigned to the right tax year.
Next step habit: Before importing a new CSV, glance at the first row's time, figure out which time zone it uses, and note it down. Then apply the Step 2 conversion to UTC. Once you are used to it, this adds less than a minute per file but eliminates cost‑matching headaches caused by time‑zone mistakes.
