Timestamp (exchange vs local)
A timestamp is the time attached to a market event: when the exchange matched a trade, when the provider sent it, or when the application received it. These three clocks differ, and a chart or a backtest must state which one it uses and in which time zone it is displayed.
Senzoukria · Glossary · Updated September 2026
Three clocks on one trade
Two applications receiving the same feed can place a trade in different one-minute bars if one uses exchange time and the other its local clock. Before comparing delta or POC across tools, confirm both build bars on the same clock.
| Clock | Set by | Use |
|---|---|---|
| Exchange (match) time | The matching engine | Ordering events and building bars consistently across sources |
| Provider send time | The data vendor's servers | Diagnosing feed delays |
| Local receive time | Your machine | Measuring latency; never for session boundaries |
Time zones and session boundaries
- CME futures sessions are defined in Chicago time; the daily boundary at 17:00 Chicago shifts against UTC when daylight saving changes, and US and European switch dates differ.
- Crypto venues run on UTC with no daily close, so a session-based indicator needs an explicit anchor.
- Displaying the axis in a local zone does not change the underlying event times; it only changes the labels.
- A level computed on one session definition cannot be compared with a level computed on another.
Timestamps in options-based context
A gamma exposure figure is a snapshot: the option chain, the open interest and the underlying price each carry their own time. Open interest is typically published once a day, so a GEX level drawn on a live ES or NQ chart mixes a daily figure with intraday prices. State the snapshot time next to the level and do not move it after the fact; a footprint response near a level is only meaningful if the level existed at that time.
In Senzoukria
The Settings page has a "Time axis timezone" option whose hint reads: LCL follows this machine, NY / CHI for futures sessions, UTC for crypto. All IANA zones map to the exact offset at render time, DST-aware. The built-in cumulative delta resets at each source session boundary, CME 17:00 Chicago or crypto UTC, and its note says that a reset does not prove full coverage. The tick export used for research writes every tick with timestamp, price, size and aggressor side, so a backtest outside the application can keep the exchange ordering.
Common mistakes
- Building session profiles on local receive time and then wondering why the opening range differs from another tool.
- Ignoring the DST week when US and European clocks are out of step.
- Placing a daily options snapshot on an intraday chart without recording when it was taken.
- Treating a bar's close time as the time the last trade was received.
Related
This page in other languages
Frequently asked questions
- Which timestamp should a backtest use?
- The exchange timestamp, in a stated time zone, with the session definition recorded alongside the rule. Using receive time introduces machine-specific delays into the historical record and makes results impossible to reproduce elsewhere. Keep the roll policy and the session boundaries in the same report.
- Why does my footprint bar differ from another platform's for the same minute?
- Check the clock and the session boundary first. If one tool builds minutes on exchange time and the other on local time, trades near the boundary land in different bars. Only after aligning the clock, price grouping and classification method should you look for missing events.
- Does a GEX level have a timestamp?
- It should. The level is derived from an option chain and open interest captured at a specific moment, usually with open interest from the previous day's publication. Record that moment and treat the level as context from that snapshot, not as a live observation.