Market data comes with timestamps that must be parsed, synchronised across time zones and stored consistently. Financial markets operate across different time zones with varying holiday schedules, making date management more complex than in many other domains. Getting date formats, time zones and software representations wrong will misalign data and corrupt results.
5.1 Data and libraries
Date handling needs a parsing library in each language and nothing else.
from datetime import datetime, timezonefrom zoneinfo import ZoneInfo
usingDates, TimeZones
5.2 Common date formats
A date can be written numerically in several ways. Consider the date 13 September 2018:
Format
Example
DD-MM-YYYY
13-09-2018
MM-DD-YYYY
09-13-2018
YYYY-MM-DD
2018-09-13
YYYYMMDD
20180913
The best way is to use the YYYYMMDD convention for two reasons:
It can be represented as an integer, not as a string, making data handling more convenient;
It sorts naturally (in chronological order).
For international data, use the ISO 8601 format YYYY-MM-DDTHH:MM:SSZ, where T separates date and time and Z indicates UTC. For example, 2025-02-10T14:30:00Z represents 10 February 2025, at 14:30 UTC.
5.3 Time zones and UTC
UTC (Coordinated Universal Time) is the primary global time standard. Financial data is often timestamped in UTC to avoid confusion across different market hours and locations.
Major financial markets operate in different time zones — New York (EST/EDT), London (GMT/BST), Tokyo (JST) and Hong Kong (HKT). Market opening and closing times must be converted to a common reference, typically UTC, for analysis across multiple markets.
Summer time changes complicate time zone handling. The US and Europe change clocks on different dates, creating periods where the time difference between New York and London varies. For example, there are brief periods when New York is 4 hours behind London instead of the usual 5 hours.
Convert all timestamps to UTC before you calculate anything on an international portfolio. This ensures that events are properly sequenced and that correlations between markets are not distorted by time zone misalignments. Many data providers offer timestamps in both local market time and UTC.
UTC and GMT (Greenwich Mean Time) are often used interchangeably, though technically UTC includes leap seconds to stay aligned with Earth’s rotation, which GMT does not. For practical financial analysis, this distinction rarely matters.
All three languages provide functions for time zone conversions, but you should verify historical dates around summer time changes manually.
5.4 How software handles dates
Software does not store dates as calendars. It stores them as numeric offsets from an epoch.
The Unix epoch (1 January 1970, 00:00:00 UTC) is the starting point for timekeeping in Unix-like systems, like Mac and Linux. Time is measured as the number of seconds elapsed since this moment, known as Unix time. For example, Unix timestamp 1740301494 corresponds to 2025-02-23T09:04:54Z.
Historical dates before 1970 use negative numbers. For instance, 1 July 1850 at noon UTC is -3771144000.
Windows file timestamps (FILETIME) count from 1 January 1601, 00:00:00 UTC and cannot represent earlier dates, which can cause compatibility issues when transferring data between systems.
Dates break most often when data moves between programs. Excel’s date origin is a workbook setting, not a property of the version — the origin year can be either 1900 or 1904, historically defaulting to 1904 on Mac — so verify it before use. Excel does not allow dates before 1900.
5.5 Parsing dates in financial data
Financial data often arrives with inconsistent date formats from different sources. All three languages provide tools for handling these variations and converting between formats commonly used in finance.
Common date format patterns:
Year-month-day (2024-02-15) — ISO standard, common in databases
Month-day-year (02/15/2024) — US convention, often in US data feeds
Day-month-year (15/02/2024) — European convention, UK data sources
A common task is converting local market times to UTC for cross-market analysis. Suppose the New York Stock Exchange closes at 16:00 Eastern Time and the London Stock Exchange closes at 16:30 London time on 21 June 2024, during summer time. We convert both to UTC.
5.7 Common date and time issues in financial analysis
When Samoa skipped 30 December 2011, moving directly to 31 December, any financial analysis spanning this period required special handling to avoid gaps in time series data.
Similarly, when Venezuela advanced its clocks by 30 minutes in 2016 with little notice, or when Russia rearranged its time zones in 2014, financial systems had to quickly adjust to maintain accurate timestamps. Morocco’s practice of suspending daylight saving time during Ramadan, with dates announced close to the event, creates ongoing challenges for automated trading systems.
Unusual time zones add complexity to global analysis. Nepal operates on UTC+5:45, one of the few 45-minute offsets in use, while North Korea introduced Pyongyang Time (UTC+8:30) in 2015 before reverting to UTC+9 in 2018. These non-standard offsets require special handling in financial systems designed around hour-based time zones. This is why financial institutions typically standardise on UTC for internal systems.
Market holidays create additional gaps in data series that must be handled appropriately in analysis. Different markets observe different holidays, meaning that correlations calculated during holiday periods may not reflect normal trading relationships.
Daylight saving time transitions can create apparent jumps or gaps in intraday data series. When clocks “spring forward”, an hour disappears, while “falling back” creates a repeated hour that can lead to duplicate timestamps if not handled carefully.
Standardise timestamps before any analysis begins. If one market reports local time and another reports UTC, the data will line up on the screen and mislead in the results.