The four sessions
Given in each financial centre's own local time, because that is what actually stays fixed:
| Session | Local hours | Character |
|---|---|---|
| Sydney | 08:00 – 17:00 | thin; sets the tone for AUD and NZD |
| Tokyo | 09:00 – 18:00 | JPY pairs, generally range-bound |
| London | 08:00 – 17:00 | the largest volume in FX |
| New York | 08:00 – 17:00 | the second largest; drives USD |
The reason to give them locally rather than in UTC is that the local hours are stable while the UTC equivalents move — see below.
The part that matters: overlaps
Volume is not evenly spread across a session. It concentrates where two sessions are open at once, and the London–New York overlap is by a wide margin the most important window in FX.
During it you get:
- the tightest spreads of the day, because the most participants are quoting
- the largest moves, because the most orders are being placed
- the most reliable execution — see slippage, which is worst when liquidity is thin
That last point cuts both ways. Thin hours are not merely quiet; they are where a market order gets filled further from your intended price, and where a stop is likeliest to be reached by a spread widening rather than by the market actually moving.
The Tokyo–London overlap is smaller and matters mostly for cross pairs.
Daylight saving moves everything
This is the part that catches people, and it is why the table above is in local time.
London and New York both observe daylight saving, but on different dates — the US changes a few weeks before Europe in spring, and a week after in autumn. Tokyo observes none at all.
Which means:
- The London–New York overlap is a different UTC window in summer than in winter.
- For a few weeks each year it is a third window, while one side has changed and the other has not.
- Tokyo's hours stay fixed in UTC while everything else shifts around them.
If you memorised the overlap as a UTC range, that memory is wrong for part of every year. If you memorised it in your own local time and you observe DST too, it may be right — or wrong by an hour, depending on whether your changeover matches theirs.
What this does to your data
Combine this with server time and the practical conclusion is uncomfortable:
Session boundaries in imported data drift against a fixed server offset. A trade at 09:00 server time is inside the London session in one part of the year and before it in another. Any tool assigning trades to sessions by raw hour, without accounting for both the broker offset and the DST schedule of the relevant city, is approximating.
For most questions the blur is tolerable. For "am I better in the London session than the New York one" on a sample spanning a year, it is not — the boundary itself moved twice inside your sample.
What is worth taking from this
Trade when the market is liquid, if your method allows a choice. Not because the overlap is magic, but because execution costs less there, and execution is the one cost you pay on every trade regardless of whether you were right.
Know which session you are actually in, in local terms rather than in your platform's clock.
Treat by-session statistics from a long sample with suspicion unless you know the tool handles both offsets. The counting is honest; the boundaries are the part that moves.