Trading Hours in a Bot: How Time Zones and DST Quietly Shift Your Strategy

Almost every automated strategy contains a time: when trading starts, when it stops, when positions are flattened at the latest. That time is often a plain constant in the code - which makes it wrong several times a year. Nothing reports the error, nothing crashes. The bot simply trades an hour off.

Three clocks that don't agree

At least three times are in play: the clock of the machine or server the bot runs on, the timestamps coming from the data feed, and the time of the exchange where the instrument trades. Trading hours are defined in the exchange's time, not in yours. Writing rules in local time ties the strategy to a clock that has nothing to do with the market being traded - which becomes especially obvious once the bot runs on a server in another region.

Why a fixed hour offset isn't enough

Europe and the United States don't change their clocks on the same day. The EU switches on the last Sunday in March and the last Sunday in October, the US on the second Sunday in March and the first Sunday in November. That creates two windows each year - roughly two to three weeks in spring, about one week in autumn - where the difference between European time and US exchange time is not what it is the rest of the year. A hard-coded offset is guaranteed to be wrong inside those windows.

The backtest is affected just as much

Historical data carries timestamps that have to be read with the offset that applied back then, not today's. Miss that, and a session anchor - the start of an opening range, say - sits on the wrong bar for entire stretches of the history. The result still looks clean, it just answers a different question than the one you asked. What makes it particularly treacherous is that the error affects only parts of the test period, so it looks like changed market behaviour.

What a time window alone doesn't cover

• Exchange holidays with no trading at all - a plain time window knows nothing about holidays
• Shortened sessions around holidays, where the usual flatten time would come too late
• Instruments with different sessions - a window that fits one instrument need not fit the next
• Futures rollover dates, when liquidity moves to the next contract

How it should be built instead

• Pick a single reference time and use it throughout, instead of converting back and forth in several places
• State the rules in the exchange's time and do the conversion only at the edges
• Handle conversion through a maintained time zone database rather than an hour constant - the switching rules do change occasionally
• Keep trading hours, the buffer before the close and holiday behaviour configurable instead of buried in the code
• Log every trade with both the reference time and the exchange time, so a shift is noticeable at all

For how scheduled events can be handled on top of the clock itself, see the article on the news filter in a trading bot.

For why the server's location matters here, see the article on a VPS for an ATAS trading bot.

Time zones aren't an exciting topic, but they're one of the few sources of error that can be avoided completely. Provided the decision is made during design - and not after the first week in which the strategy traded an hour off.