Market session clock and timezone converter
“This time is quoted in somebody else's clock — what is it in mine, and which sessions were open at that moment?”
Three things bite traders on timezones: a broker export whose stamps are in the broker's zone, an economic release quoted in the venue's local time, and a prop firm's daily reset, which is a wall clock in Chicago or CET. This converter answers all three, and it reports the day roll — the half of the answer a time-only converter drops.
Free to use, nothing to sign up for, and nothing you type here is sent anywhere — the arithmetic runs in your browser.
What it computes
1. The from-zone wall clock is solved to a UTC instant (two passes, because the offset in force depends on the instant being solved for). 2. That instant is read on the to-zone clock: date, time, and the UTC offset actually in force on that date. 3. Whole days between the two dates -> same day / next day (+1) / previous day (-1). 4. Sydney, Tokyo, London and New York at that instant, each on its own calendar.
What you type in
| Field | What it means | Example |
|---|---|---|
| From timezone | The zone the time you have is quoted in. | Your browser's zone |
| Date | Calendar date in the from-zone. | 2026-07-07 |
| Time | Wall clock in the from-zone, 24-hour. | 21:00 |
| To timezone | The zone you want it read in. | New York |
Reading the result
- The converted time, with the UTC offset in force on that date rather than today's.
- The day roll: same day, next day or previous day. This is what decides which trading day a fill belongs to.
- The four major sessions at that instant, each with its own local clock, its own weekday and open or closed with the reason.
Worked example
A fill stamped 2026-07-07 21:00 in a broker export that is quoted in Tel Aviv time.
- From Asia/Jerusalem 21:00, read in America/New_York: 14:00 on 2026-07-07, same day, UTC-04:00
- New York open (09:30-16:00 local); London closed, it is 19:00 there
- Tokyo and Sydney closed
- A day-roll case: 08:00 on 2026-07-08 in Tokyo reads as 19:00 on 2026-07-07 in New York — previous day
So that fill belongs to the 7 July US session, not the 8th — which is what storing 21:00 and reading it as New York time would have implied. Same instant, different calendar date, and a different trading day in every report.
What trips people up
- The offset shown is the one in force on that date, not today's. 09:30 New York is 13:30 UTC in July and 14:30 UTC in January.
- Half-hour and 45-minute zones are real. Mumbai is UTC+05:30 all year, and any model assuming whole hours is wrong for a large part of the world.
- The weekend is judged on each session's own calendar. Sunday evening in New York is already Monday in Tokyo.
- Regular cash-equity hours only — no pre- or post-market, no exchange holidays, no futures overnight sessions. It is a clock, not a trading calendar.
Questions
- Which timezones can I pick?
- 54 of them, covering every UTC offset in use, including the half-hour and 45-minute ones. UTC is first, because it is the one unambiguous answer when a file does not say which zone it means. The full IANA list is about 400 entries of mostly identical offsets, so each offset gets the places traders look for rather than all of them.
- Does it handle daylight saving?
- Yes, on the date being converted rather than today's date. That distinction is the whole point — a converter with a fixed offset table is right for about eight months a year.
Related calculators
These are the same calculators built into Ledger of Alpha, where they read your own trade history instead of numbers you re-type. See the full product
Keep the record these numbers come from
A free account logs the trades you size here, so the win rate and averages you type into these calculators come from your own history rather than a guess.