Futures fundamentals
Futures Trading-Session Dates, Timezones & DST
Futures trade nearly around the clock across time zones, so "what date did this trade happen on" has more than one honest answer depending on whether you mean the calendar date, the trading session, or a specific timezone's wall clock. Getting this wrong doesn't just look confusing — it silently shifts which day a trade's P&L counts toward when you review results by day.
Calendar date
The calendar date is whatever date it is in whatever timezone you're looking at the clock from — the simplest, and most ambiguous, way to date a trade, since it changes depending on which timezone you or your broker's export happen to be using at that moment.
Trading-session date
A trading session is the exchange's own definition of "one day" of trading, and it doesn't line up with midnight-to-midnight. Most CME futures products open around 6:00pm Eastern Time and run through the next afternoon — so a position opened at 7:00pm ET on a Tuesday belongs to Wednesday's trading session, not Tuesday's, even though the calendar still says Tuesday where you are. This is the definition that actually matters for daily P&L, daily-loss limits, and drawdown tracking, since those are firm/session concepts, not clock-midnight concepts.
UTC, ET, and why the difference matters here
A raw timestamp with no timezone attached is ambiguous the moment it crosses a boundary — the same instant reads as one calendar date in UTC and a different one in US Eastern Time (ET), which is where most CME futures session conventions are anchored. Broker exports, journaling spreadsheets, and even trading platforms don't all timestamp in the same zone by default, which is exactly how two tools can disagree about which day a trade belongs to without either one being technically wrong.
Daylight saving time
Eastern Time itself shifts twice a year (EST/EDT), which means a fixed UTC offset hard-coded into a spreadsheet formula or script quietly becomes wrong for half the year. Correct session-date logic has to resolve against the actual IANA timezone (America/New_York), not a fixed number of hours, so the session boundary lands on the right wall-clock hour year-round.
How Fillbook actually resolves a trade's date
Fillbook computes each trade's session date from its recorded entry time, converted to America/New_York wall-clock time (DST-aware, via the timezone itself rather than a fixed offset), and rolls it to the next calendar day once that Eastern-Time hour reaches the session rollover point. This is what Dashboard, Reports, and Calendar all read from for "which day did this trade count toward." When a trade has no recorded entry time (an imprecise or date-only import), Fillbook falls back to that trade's plain recorded date rather than guessing a session — an explicit limitation, not a silent approximation.
Session date = entry time converted to America/New_York, rolled to the next day once the ET hour reaches the session-open hour (currently 6:00pm ET)
What this means when you're reconciling your own numbers
If a broker statement, a spreadsheet, or another platform's daily total disagrees with Fillbook's by exactly the trades that happened in the evening ET hours, check which date basis each one is actually using before assuming a data error — an evening trade landing on "today" in one tool and "tomorrow" in another is usually a session-vs-calendar-date difference, not a missing or duplicated trade.
Stop reconciling dates by hand across tools
Fillbook resolves session dates consistently across Dashboard, Reports, and Calendar from the moment a trade is logged — no separate spreadsheet convention to maintain.
Start free trial →Frequently asked questions
Because futures trading sessions roll over in the evening Eastern Time, not at midnight — a trade placed after that rollover point belongs to the next session's date, which is the convention Fillbook's daily P&L, Calendar, and drawdown tracking follow.
No — the session boundary is anchored to America/New_York (Eastern Time) regardless of where you personally are, since that's the timezone CME session conventions are actually defined against. Fillbook converts your trade's recorded entry time to Eastern Time internally to resolve the session date correctly no matter your own local timezone.
It shouldn't, if the logic resolves against the real America/New_York timezone rather than a fixed UTC offset — that's exactly the distinction that keeps a session boundary landing on the correct wall-clock hour across the DST changeover instead of drifting by an hour for half the year.
Fillbook uses that trade's plain recorded date instead of guessing a session date — stated as an explicit limitation for imprecise or date-only imports, not silently treated as equivalent to a session-resolved date.
See how this fits into futures-specific journaling on Futures Trading Journal — Fillbook.Track this by hand first with the Free Futures Trading Journal Template (Spreadsheet) — Fillbook.