Time zones in pandas: the silent bug
Posted: Fri Oct 30, 2026 2:04 pm
Time zones in pandas: the silent bug
Python's pandas library is a favorite for tick analysis, and its time zone handling has several traps.
Timestamps without a time zone are "naive", and arithmetic between naive and aware timestamps either fails or silently assumes the wrong zone. Data loaded from a CSV is naive by default. Converting it to UTC without first declaring its original zone can shift everything by hours.
Daylight saving transitions create ambiguous or nonexistent times. In autumn, one hour occurs twice. In spring, one hour never occurs. Operations on local-time data can duplicate or drop rows around these dates.
Grouping by day depends on the zone. A daily summary in UTC splits sessions differently from one in New York time.
The safest approach is to convert everything to UTC at the moment of loading, keep it in UTC throughout, and convert to a local zone only for display.
A test: check the number of rows per day around the DST change dates. If a day has 23 or 25 hours' worth of data in a UTC series, something went wrong.
These issues rarely trigger errors. They quietly distort results until someone notices that the London open looks an hour early.
Stored tick data: which time zone convention does the setup use?
Python's pandas library is a favorite for tick analysis, and its time zone handling has several traps.
Timestamps without a time zone are "naive", and arithmetic between naive and aware timestamps either fails or silently assumes the wrong zone. Data loaded from a CSV is naive by default. Converting it to UTC without first declaring its original zone can shift everything by hours.
Daylight saving transitions create ambiguous or nonexistent times. In autumn, one hour occurs twice. In spring, one hour never occurs. Operations on local-time data can duplicate or drop rows around these dates.
Grouping by day depends on the zone. A daily summary in UTC splits sessions differently from one in New York time.
The safest approach is to convert everything to UTC at the moment of loading, keep it in UTC throughout, and convert to a local zone only for display.
A test: check the number of rows per day around the DST change dates. If a day has 23 or 25 hours' worth of data in a UTC series, something went wrong.
These issues rarely trigger errors. They quietly distort results until someone notices that the London open looks an hour early.
Stored tick data: which time zone convention does the setup use?