A lot is made of ensuring the accuracy of your historical data in backtesting, but I have not read much about the importance of GMT offsets, daylights savings time, and the impact they can have in your results. When discussing systems based on price action which can be traded around the clock, this may not be a considered factor, but while developing an algorithmic system based around the London session, I ran into issues ensuring my entries and exits corresponded with the open and close of the market throughout the year and that my historical data GMT offset match my broker’s time when moving to forward testing. After some digging on the subjects, here’s what I’ve learned:
- GMT equals UTC – Greenwich Mean Time is the same as Coordinated Universal Time, and neither use daylight savings time.
- The New York Close offset is GMT +2 and GMT +3 during DST – Some brokers and traders alike prefer to trade off the New York close as the end of the daily session. This cleans up the charts a little and removes any pesky Sunday bars. If you are importing data from an outside source, you need to know what GMT time the data is using and offset accordingly for your charts. My broker is GMT +0 and so is Dukascopy, my source for historical data. If I wish to use the NY close, I would have to first contact my broker to make the change for my account, then make sure to offset Dukascopy data +2 GMT so that backtesting and forward testing match.
- DST needs to be accounted for in Algorithmic Strategies – The strategy I am developing is based around the popular London breakout strategies. I won’t get into the specific rules here (you can find dozens online), but it hinges on the open of the London session. If I write code to open an order at the 8:00 GMT candle, the London open, this code would fail or give inaccurate results in the summer, when the open is shifted to 7:00 GMT for daylight savings time. I stumbled upon this by looking at the equity curve of earlier tests. There as a huge drawdown during the summer months. This could be due to DST or just a poor strategy, but there is no way to know which unless I incorporate this into my backtesting. Birt’sTick Data Suite has a handy option to compensate for DST (shown below) to make my earlier code work, but a better solution will need to be used for EAs to run accurately on a Live account.
Live Chart with DST
Backtesting Chart with DST offset selected