Timestamps, Time Zones and Daylight Saving

Every price, signal and order happens at a moment in time, and getting that time right is surprisingly hard. Markets operate in different time zones, daylight saving rules shift sessions twice a year on different dates in different countries, and data vendors label bars in different ways. A one hour error can make a strategy trade on information it should not have yet, or miss the session it was designed for. Most timestamp bugs are invisible: the code runs, the backtest finishes and the results are simply wrong.

Golden rule: store in UTC#

Store every timestamp in Coordinated Universal Time (UTC), which has no daylight saving changes. Convert to local exchange time only when you need it, such as finding the New York open or displaying a chart. Mixing local and UTC timestamps in the same dataset is one of the most common sources of silent errors.

Daylight saving traps#

Because the US and Europe change on different dates, for a few weeks each year the gap between New York and London is four hours instead of five. A strategy trading the overlap of the London and New York sessions must handle this. See Forex Trading Sessions and Trading Sessions.

Use time zone names, not fixed offsets#

Write "America/New_York" or "Europe/London" rather than "UTC minus 5". Named zones from the IANA time zone database know the historical and future daylight saving rules. In Python, use the zoneinfo module or pandas' tz_localize and tz_convert.

import pandas as pd
ts = pd.Timestamp("2026-07-15 09:30").tz_localize("America/New_York")
print(ts.tz_convert("UTC"))   # 2026-07-15 13:30:00+00:00

Event time versus receive time#

Backtests should use the time information was available to you, which is close to receive time, not event time. The gap between them is your latency. See Exchange vs Receive Timestamps and Latency Measurement.

Bar labels#

A bar labelled 10:00 might cover 10:00 to 10:01 (start label) or 9:59 to 10:00 (end label). Daily bars may be labelled with the date but close at 16:00 New York time, which is the next calendar day in Asia. Always confirm the convention and treat a bar as known only after its end. See Tick Data and OHLCV Data and Look-Ahead Bias.

Data release times#

Economic data, earnings and other events have specific release times. A US jobs report at 8:30 Eastern is known at that moment, not at midnight of that date. Fundamental data in databases is often stamped with the period end date, not the date it was published. See Point-in-Time and Survivorship-Free Data and Employment Data and Non-Farm Payrolls.

Precision and clock accuracy#

Use millisecond or finer precision for intraday data. Make sure your own servers' clocks are synchronised, since a drifting clock corrupts every receive timestamp. See Clock Synchronization and PTP.

Frequently asked questions#

Why should I store trading data in UTC?#

UTC has no daylight saving changes, so timestamps stay consistent and comparable across markets and seasons.

How does daylight saving affect trading?#

It shifts session times relative to UTC, and different regions change on different dates, which alters session overlaps for a few weeks each year.

What is the difference between event time and receive time?#

Event time is when something happened at the exchange; receive time is when your system learned about it. Backtests should respect receive time.

Next, learn how splits and dividends change price history in Splits and Dividends in Price Data.