The timezone shift hiding in downloaded data
Posted: Sat Oct 31, 2026 10:06 pm
A file of tick data has timestamps, and the timezone isn't always stated. Some are in UTC. Some are in the broker's server time, which may be GMT+2 or GMT+3 depending on daylight saving. Some are in the vendor's local time.
If the strategy depends on time of day, such as trading only during the London open, a shifted timestamp can ruin the test. The trades happen at the wrong hours, and the result reflects a different market.
The error can be subtle. A one-hour shift moves the London open into the pre-London period, where spreads are wider and volatility differs. The strategy seems to work but only because the test is trading in unintended conditions.
Daylight saving makes it worse. A fixed offset applied to a whole year becomes wrong for half of it.
The check is easy. Plot average volatility by hour in the data. The London open and the New York open should produce visible jumps at known UTC hours. If the jumps appear an hour early or late, the timezone is wrong.
One more place where timezone bites is the rollover itself. The day boundary used by a data vendor may sit at 5pm New York, at midnight UTC, or at the broker's server midnight. A strategy that resets a counter at the start of each day will reset at different real times, which changes how many trades it takes before hitting a daily limit.
A good habit is to write the timezone in the filename of every data set and in the header of every test report. It looks fussy, but a single missing label can cost a week of confusion later when two results refuse to match.
Is the timezone of the data verified before testing time-based logic?
If the strategy depends on time of day, such as trading only during the London open, a shifted timestamp can ruin the test. The trades happen at the wrong hours, and the result reflects a different market.
The error can be subtle. A one-hour shift moves the London open into the pre-London period, where spreads are wider and volatility differs. The strategy seems to work but only because the test is trading in unintended conditions.
Daylight saving makes it worse. A fixed offset applied to a whole year becomes wrong for half of it.
The check is easy. Plot average volatility by hour in the data. The London open and the New York open should produce visible jumps at known UTC hours. If the jumps appear an hour early or late, the timezone is wrong.
One more place where timezone bites is the rollover itself. The day boundary used by a data vendor may sit at 5pm New York, at midnight UTC, or at the broker's server midnight. A strategy that resets a counter at the start of each day will reset at different real times, which changes how many trades it takes before hitting a daily limit.
A good habit is to write the timezone in the filename of every data set and in the header of every test report. It looks fussy, but a single missing label can cost a week of confusion later when two results refuse to match.
Is the timezone of the data verified before testing time-based logic?