A trading journal is easier to compare when every event keeps its original timestamp and time zone alongside a UTC equivalent. A local clock reading without a zone can be ambiguous, especially when civil-time rules change.
Why a local timestamp can mislead
A timestamp such as 01:30 is not a complete point in time by itself. You also need its date and the zone or UTC offset that applied. Python’s datetime documentation distinguishes aware values, which can locate a specific moment, from naive values that do not carry enough information to do so (Python datetime documentation); the IETF’s timestamp standard likewise explains why applications may need a time-zone name alongside an instant (RFC 9557).
That distinction matters in a journal. Two records both labelled 09:00 may refer to different moments if one uses a broker’s server clock and the other your computer’s local clock. Do not infer the zone from the symbol, the market name or the computer’s current setting.
A record format that survives clock changes
For each trade or review event, retain the source value and add explicit context:
| Field | What to record |
|---|---|
| Original timestamp | Exactly as shown by the platform or broker |
| Stated zone or UTC offset | The source’s documented zone, or the offset shown for that timestamp |
| UTC equivalent | A converted timestamp, labelled UTC |
| Origin | Account, platform, export or personal note |
| Session label | Your chosen session name, separately from the timestamp |
The IANA Time Zone Database records local-time history and is updated when political bodies change time-zone boundaries, UTC offsets or daylight-saving rules (IANA Time Zone Database). That is why a fixed offset such as “UTC−5” should not be treated as a permanent synonym for a city or region. Use a named zone and a maintained rule set when converting historical local times.
Check the repeated-hour edge case
When clocks move back, a local wall-clock time can occur twice. Python’s zoneinfo documentation models these ambiguous times with the fold attribute (zoneinfo documentation); the IETF also describes how civil-time transitions can complicate the association between local times and instants (RFC 9557). If an export contains a repeated hour but no offset or other disambiguating information, do not guess which occurrence a trade belongs to. Preserve the raw export, mark the conversion unresolved, and check the platform’s timestamp convention or another record with a known time.
A hypothetical example: your notes say 01:20, while the platform export also says 01:20 on the date clocks moved back. Those strings alone cannot establish that the entries happened together. Keep both originals and compare only after the applicable zone and offset are known.
This workflow does not decide which bars belong to a broker’s trading session. UTC helps align moments; session boundaries and candle construction remain platform- and instrument-specific. For a separate cTrader clock audit, see how to test daylight-saving changes in a cTrader backtest and the cBot decision-log checklist. realbacktesting is a trading-software studio for cTrader; its published cBot results are designed to be checked in the platform, as described in our reproducibility notes.
Frequently asked
Should I store every trading timestamp in UTC?
Store a UTC equivalent for comparison, but keep the original value and its source context. UTC alone does not tell you which broker session or candle rule was used.
Is a UTC offset the same as a time zone?
No. An offset describes the difference from UTC at a particular time. A named time zone carries rules that can vary across dates; consult a maintained time-zone database such as IANA’s.