Pandas and the repeated hour on 25 October 2026, when UK clocks go back

[Fairman]

Pandas and the repeated hour on 25 October 2026, when UK clocks go back

UK clocks go back at 02:00 on Sunday 25 October 2026, so the hour from 01:00 to 01:59 happens twice, once in BST and once in GMT. If a trade log has local timestamps without an offset, 01:30 on that day is ambiguous, and there's nothing in the file to say which one it is.

In pandas, localizing such a column with tz_localize('Europe/London') raises an AmbiguousTimeError on those rows. The ambiguous argument gives three ways out: 'infer' works only if the rows are in time order and cover the whole repeated hour, 'NaT' blanks the ambiguous times, and a boolean array lets you state for each row whether it's the first pass (True means DST).

The spring change has the opposite problem. On 29 March 2026 the hour from 01:00 to 01:59 never existed, and tz_localize raises NonExistentTimeError unless you pass nonexistent='shift_forward' or similar.

The cleaner fix is to avoid local time in the stored data. Store UTC. MT5 deal times are in server time, which is often GMT+2 or GMT+3 depending on the season rather than UTC, so converting them needs the right offset for each date. The server's own clock changes follow a different calendar, which means the offset between server time and UTC changes on a date that isn't today's.

[Fairman]

Test with a synthetic frame, not the real file. Build five minute rows from 00:00 to 04:00 on the 25th in UTC, convert to Europe/London, and check the day's length. A local calendar day on 25 October has 25 hours, which is 300 M5 bars instead of 288. On 29 March it has 23 hours, or 276 bars. If your daily statistics group by local date, those days have different numbers of bars, and any code with a hard coded 288 will quietly misbehave twice a year. A unit test with those two dates takes a few minutes to write and avoids two mystery bugs every year.

[Amanhasnoname]

This caught me out last year, though with my own trade log rather than pandas. I export trades from MT5 and convert them to London time for a session breakdown, and in the October change I had two trades with the same 01:15 timestamp, an hour apart in reality. My spreadsheet silently sorted them the wrong way round, and the profit for that night looked like it came from a trade that actually closed later.

Since then I store everything in UTC and only convert for display. The trick for MT5 server time was to log the broker's offset for each trade at the moment it happens, by comparing TimeCurrent with TimeGMT inside the EA and writing the difference into the record. That way I don't have to rebuild the broker's daylight saving calendar afterwards.

The unit test idea from the second post is something I'd recommend too. I added a check that counts M5 bars per local day and flags anything other than 288, and it found two broker data gaps I didn't know about as well as the clock change days.

[Fairman]

Day boundaries matter for daily loss limits. A firm that resets at 22:00 UTC doesn't use calendar days, so grouping by the date column gives the wrong day for any trade between 22:00 and midnight. A neat way is to shift first: add 2 hours to the UTC timestamp and then take the date, so a deal at 22:30 UTC falls on the next day's bucket. Put the shift in one helper function so every report uses the same boundary. Then the question of whether the reset moves with the clocks becomes a single parameter you can change, not something spread through ten scripts.

[Fairman]

For files that need local time, write timestamps in ISO 8601 with an offset, like 2026-10-25T01:30:00+01:00 for the first pass and 2026-10-25T01:30:00+00:00 for the second. Each one is unambiguous, and pd.to_datetime with utc=True parses a column of them into one clean UTC series. Watch for spreadsheet programs that drop the offset when they save, so the file you reload no longer carries it. If a CSV goes through Excel, check the column afterwards, or keep a second column with a UTC epoch in seconds that no program is likely to reformat.

[Fairman]

A VPS often ships with a timezone you didn't choose, commonly a US one on a rented Windows box. File names with dates in them, log timestamps, scheduled tasks and the terminal's journal all follow the machine's clock, so moving it to UTC gives you one reference that never changes. The MT5 server time stays the broker's, which is a separate thing, so keep both written down. Having log lines in UTC and trade times converted from server time into UTC as well means a line in one file can be matched to a line in another without arithmetic on the night the clocks change.

[FXS HongKong Scalper]

Storing all timestamps in UTC from the start avoids the problem entirely. If the log comes from MT5, the server time can be converted to UTC using the known server offset. For traders in Hong Kong, local time has no daylight saving changes, so logs kept in Hong Kong time do not have repeated hours. Mixing such logs with broker data in London or New York time is where the issues appear, and converting everything to UTC first keeps it simple.