Crypto records off by one day? Align UTC timestamps before reconciling

If your crypto records are off by one day, check the timestamps before adding a missing transaction to your trading log. A record shown in local time and an export recorded in UTC can refer to the same instant on different calendar dates. Start with one disputed entry, preserve the original files, and compare full timestamps rather than date labels alone.

This guide is for readers reconciling downloaded activity with a confirmation or another record. It addresses time alignment; it does not assume that every missing entry is a timezone problem.

Find out which time each source actually records

Write down the source of each timestamp: the export column, account history view, or confirmation. Look for a documented timezone or an explicit numeric offset. Do not assume that an export uses your computer's timezone simply because the account page looks familiar.

Kraken provides a useful concrete reference: its ledger field documentation says the time field contains both date and time in UTC.

The time-field row from Kraken's public ledger documentation, captured on October 14, 2026. This is a documentation screenshot, not a customer's transaction record.

That statement applies to the documented ledger field. It does not establish the timezone of every Kraken screen, a bank statement, or another exchange's file. Check each source separately. If a timestamp has no timezone and its documentation does not resolve that, label the zone as unknown rather than guessing.

Preserve the raw value before opening or changing a CSV

Keep the downloaded file unchanged and use a separate working copy. For the entry under review, retain these fields together:

This separation lets you undo a mistaken conversion without reconstructing the original. For a broader archive routine, see which transaction records to keep for reconciliation.

If you use Excel, take care with automatic CSV interpretation. Microsoft explains that opening a CSV uses current default data-format settings, which can interpret a date differently from its source format. Use the text/CSV import workflow and inspect the preview before loading; preserve the original timestamp column as text where the import tool permits it. See Microsoft's CSV import guidance and column-format options in the Text Import Wizard.

Changing a cell's displayed date format does not establish which timezone the original timestamp represents. Resolve the meaning of the value before converting it.

Convert once, then compare the full timestamp

Use UTC as the common comparison basis. The rule is UTC = local time minus its UTC offset. A positive offset is subtracted; a negative offset is added. RFC 3339 defines this relationship and explains that local daylight-saving rules can change. Use the offset applicable to the recorded event, not automatically today's offset. Source: RFC 3339, sections 4.1–4.2.

For a conversion-only illustration, 2026-10-14T00:30:00+08:00 and 2026-10-13T16:30:00+00:00 represent the same instant. These are example timestamps, not reported trades. The date changes because subtracting eight hours crosses midnight.

In your working copy:

1. Confirm whether the source is already UTC. If it is, do not apply a second offset.
2. Keep the original timestamp and put the converted value in a new field.
3. Retain the time of day during matching; do not reduce both values to dates first.
4. Compare identifiers, asset, amount, and activity type alongside the time.

A matching timestamp is supporting evidence, not a unique transaction identifier. Two entries can occur at the same time, and different stages of one transfer need not share a timestamp. Keep separate events separate unless the records explain their relationship.

Check the export window before declaring an entry missing

If the entry sits near midnight at the start or end of your selected period, inspect the adjacent date too. A practical diagnostic is to obtain a wider export and compare the individual records inside it. Preserve the original narrower export so you can explain what changed.

Do not assume a date selector and an exported timestamp necessarily use the same convention without documentation. Also avoid appending the wider export to the earlier file as though every row were new. Overlapping downloads can contain the same records; compare identifiers and source details before excluding a duplicate from your working view.

If the expected activity is absent from the correct time window, check the report type next. For example, our guide to finding instant purchases missing from a Kraken Trades CSV explains a report-selection issue that shifting timestamps will not fix.

Decide whether the mismatch is actually resolved

Close the check only when you can explain the difference using the original timestamp, its timezone evidence, and the matching record details. Keep both original values even when they normalize to the same instant.

If the values still disagree, write down the remaining question precisely: unknown timezone, different event stage, missing identifier, or an entry absent from the source report. Send that focused question through the platform's official support channel if needed. Share only the relevant excerpt privately; remove unrelated activity and personal information.

Do not insert a balancing transaction, change an amount, or delete a source row merely to make daily totals match. Time alignment should explain the existing evidence. When it cannot, leave the discrepancy visible for further investigation.