Every trade in your journal carries a plain date and time — 21:52, not “21:52 in Tel Aviv”. For that to mean anything, the app has to know which clock those numbers are on. That clock is your Trade Timezone, and there is exactly one of it: Settings → Chart → Trade Timezone. Set it to the exchange clock you think in. Everything else on this page follows from it.
Why it matters more than it looks
A time that is a few hours out is rarely a few hours’ worth of wrong. It moves the trade to a different day, and the day is what almost every summary is built from: your daily P&L, the calendar, a goal’s week or month, the review period — and, on a prop-firm account, the firm’s trading day, where a trade landing on the wrong side of the daily reset can look like a rule breach that never happened.
Importing a CSV from a broker in another timezone
Broker exports are stamped in whatever timezone the broker chose, and most files never say which. So the import preview asks, before anything is saved:
- A Times banner at the top of the preview names both clocks — the one the file is being read as, and the one your journal stores.
- Change “This export is stamped in…” to the broker’s timezone and the file is re-read on the spot. The banner then tells you how many trades were re-stamped and, separately, how many moved to a different day.
- If the file writes a real timezone designator on its timestamps (an ISO stamp ending in
Zor-05:00), the file has already answered the question and those rows are converted from what it says — the picker is not consulted for them. - Rows with a date but no time are left exactly as they are. There is no instant to convert, and pretending they happened at midnight is how a date gets moved for no reason.
Got it wrong and already imported? Fix the picker and import the same file again. Duplicate detection is keyed to the fills in the file, not to the times we stored, so the re-import is recognised as the same trades rather than doubling your book — delete the originals and keep the corrected rows.
Tradovate and TopstepX are handled for you
The two prop platforms show the banner read-only. TopstepX writes UTC and is converted to Chicago by its own importer; Tradovate is stored exactly as the file writes it. Both are wired to the firm-day arithmetic your prop rules run on, so they are deliberately not yours to move. See Importing from Tradovate and TopstepX.
Typing a fill on a different clock
Next to Entry on the trade form there is a small timezone badge and picker. It says which clock the date and time boxes are showing, and you can change it — useful when you are reading a fill off your broker’s platform in your own local time while your journal runs on exchange time.
It is a view, not a conversion you have to be careful with. Pick your own city, type the time you see, and the journal stores the same instant on its own clock. Switch the picker back and the original numbers return — changing it never edits the trade, and the choice is remembered on this device for your next entry.
Daylight saving is handled
Conversions use the offset that was actually in force on that date, not a fixed number, so a trade in January and a trade in July convert differently and both are right. One oddity worth knowing: on a spring-forward morning some clock times never happen — 02:30 does not exist in New York on the day the clocks jump from 02:00 to 03:00. If you enter one, it is read as the hour before rather than rejected.
What is not affected
Changing your Trade Timezone does not rewrite trades you have already saved — it changes how their stored times are interpreted from then on. If you set it after importing a long history, the cleanest fix is to re-import that history with the source timezone declared.