Why London–New York Forex Overlap Shifts: Rebuild It by Trade Date

A London–New York overlap schedule can become wrong by an hour even when neither city changes its local working hours. The United States and the United Kingdom move their clocks on different dates. For part of March and late October, their time difference is four hours rather than the usual five. The overlap can therefore change in length as well as in its UTC start or end.

The practical answer is to calculate the intersection for the date you intend to analyse, using an explicit local-time definition for each city. With the illustrative 08:00–17:00 windows used below, the overlap lasts four hours when both cities use standard time or both use daylight time, but five hours when New York is on daylight time while London is on standard time. These are calculated clock windows, not evidence of five hours of favourable trading conditions.

Define the two windows before looking for an overlap

Spot foreign exchange is an over-the-counter market with trading spread across dealers and venues. A label such as London session does not establish one official opening bell, one compulsory closing time or access through every account. Your provider can impose its own product hours, maintenance breaks and holiday arrangements.

For a reproducible example, assume that the London working window is 08:00–17:00 in London and the New York working window is 08:00–17:00 in New York. Both are attached to the same local calendar date, and both exclude their ending instant. These are deliberately chosen analytical inputs; they are not asserted to be the hours of any particular dealer or venue.

Keep the date and the city with the clock reading. London 08:00 and New York 08:00 are different instants. A bare label such as EST should not stand for New York time throughout the year: EST is UTC−5, whereas EDT is UTC−4. Likewise, London uses GMT, equivalent to UTC for these conversions, or BST at UTC+1. Beijing time in all the examples is UTC+8.

Use the actual US and UK change dates

For 2026, the US daylight-saving period starts on March 8 and ends on November 1; the changes occur at 02:00 local time. UK clocks go forward on March 29 and back on October 25. The current US rule uses the second Sunday in March and first Sunday in November, while the UK uses the last Sunday in March and October.

Consequently, the weekday examples from March 9 through March 27 have London on GMT and New York on EDT. The same offset combination applies from October 26 through October 30. London is then four hours ahead of New York. Outside those mismatch periods, the examples with GMT/EST or BST/EDT have a five-hour difference. Recheck the rules for other years rather than copying these dates into a permanent calendar.

A local clock moving forward makes the same local working hour occur one hour earlier in UTC. It does not move UTC itself. In spring New York makes that move first; in autumn London moves back first. That asymmetry explains why one overlap boundary can move while the other stays put.

Convert both intervals, then take their intersection

Convert each endpoint using UTC time = local time − that city’s UTC offset on that date. Once all endpoints refer to UTC, the overlap starts at the later opening and ends at the earlier closing. Its duration is the larger of zero and end minus start. Use full timestamps, not only clock faces, if an interval crosses midnight.

On March 9, for example, London’s assumed window becomes 08:00–17:00 UTC and New York’s becomes 12:00–21:00 UTC. The later start is 12:00 and the earlier end is 17:00: five hours. On March 30, London becomes 07:00–16:00 UTC while New York stays at 12:00–21:00 UTC, reducing the intersection to four hours.

All dates in the first column are 2026 London/New York calendar dates. The final column explicitly carries the ending timestamp into the next Beijing calendar day. For example, October 23 at 16:00 UTC is October 24 at 00:00 in Beijing, not October 23 at midnight. The interval includes its start but excludes its end: exactly 16:00 UTC is outside the October 23 overlap.

These are calendar calculations under the stated inputs, including the November 2 illustration, not observations of actual trading on those dates. The autumn sequence is especially revealing: October 23 to October 26 leaves the UTC start unchanged and moves the end one hour later; October 26 to November 2 leaves the end unchanged and moves the start one hour later. Shifting an entire rectangle by one hour cannot describe both transitions.

A fixed four-hour filter can include the wrong hour and miss the right one

Suppose a research script keeps every observation from 12:00 inclusive to 16:00 exclusive UTC on each date because that matched its summer setup. Compare that frozen filter with the date-specific overlap. Hours incorrectly included below are outside the assumed overlap, not necessarily outside the product’s trading hours.

On November 2 the script still selects four hours, just as the correct window does, but only three hours are shared. It wrongly includes 12:00–13:00 and omits 16:00–17:00. An unchanged row count or duration can therefore hide a different sample of prices. With complete one-minute observations timestamped at each minute’s start, both filters contain 240 rows but only 180 are common; each has 60 rows the other lacks. Missing data would require a separate count check.

For an intraday backtest, rebuild the timestamp membership before comparing spreads, ranges or returns. A bar straddling a window boundary is not wholly inside it merely because its label is inside. Specify whether you use event timestamps, fully contained bars or another documented rule; use finer data if an exact split is needed. Daily candle construction is a separate issue explained in why forex daily candles can differ when their closing times differ. Changing a chart’s display timezone does not by itself repair either calculation.

Confirm the clock explanation without assuming better execution

A timing explanation is supported when the two local schedules stay unchanged, the official offsets change as expected, and converting the recorded timestamps reproduces the new UTC boundaries. Check a timestamp just before the start, the start itself and the excluded end. If those tests disagree, investigate the stored timezone, server offset or interpretation of the date before using the session label.

The calculated overlap is only as applicable as its inputs. A holiday, a reduced working day, a different dealer schedule or a product break can make 08:00–17:00 an unsuitable representation. A data release remains attached to the time basis in its own calendar; it should not be moved simply because an overlap label moved. Product availability, settlement calendars and the two-city overlap are different checks.

Even an accurately mapped overlap does not guarantee a narrow spread, available size or a filled order. More potential participants do not determine the quote available to a particular account, and a volatile event can change execution conditions within the window. Examine the same currency pair, quote source, bid and ask timestamps, intended quantity and actual fill records. A large candle is not a measurement of executable liquidity.

If the practical question is whether this window improves execution, compare like-sized orders and like-for-like quotes across a defined sample, separating event days, holidays and missing observations. Clock arithmetic confirms membership; those observations test execution quality. Without them, the time window alone cannot establish an advantage.

Build a date-aware schedule you can audit

First record the analysis date, pair and product, each assumed local interval and its named timezone. For software, use date-aware zone identifiers such as Europe/London and America/New_York with current timezone data, rather than a permanent subtraction of four or five hours. Preserve the original timestamps and the data or server timezone instead of overwriting them with unlabeled local times.

Next convert both windows to UTC, calculate their intersection and convert the resulting full timestamps to your display zone. Save the start date, end date, offsets and duration together. For the six dates in the first table, the durations must be 4, 5, 4, 4, 5 and 4 hours. Add a test at the excluded endpoint and a test for the next-day Beijing date.

Then check the relevant provider’s actual hours and exceptional closures, and align the economic calendar and data timestamps separately. If a schedule is defined in fixed UTC rather than fixed local time, leave that definition intact: it is a different input, not an error to be silently corrected. If a future local boundary falls within a repeated or skipped clock-change hour, specify the timezone’s ambiguity rule instead of guessing; the weekday daytime examples here avoid that problem.

Finally regenerate the schedule when either clock rules or the chosen working intervals change. Record the assumptions beside the resulting window. The reliable output is a dated, testable interval and an explicit scope—not a year-round claim that London and New York always overlap at the same hours.