Normalize timestamps at the boundary, preserve their meaning, and format them only for display.
Give every timestamp a meaning
A field called time can represent a quote observation, the start of a candle, or the moment a server received a message. Those are different events. Document which event each field describes before sorting records or calculating freshness.
Our suggested internal model keeps observation time and receipt time separate. For candles, retain the interval start and the interval definition. Avoid replacing a missing source timestamp with the current time: that turns missing information into a false claim about when the price was observed.
Make units and offsets explicit
RFC 3339 defines an Internet timestamp format with a date, time, and offset. The Z suffix denotes UTC; a numeric offset describes the relationship of local time to UTC. An offset alone does not identify a region or its daylight-saving rules.
For example, 2026-10-09T08:00:00Z and 2026-10-09T16:00:00+08:00 describe the same instant. If your API instead returns numeric epoch timestamps, consult its contract for the unit. Seconds and milliseconds differ by a factor of 1,000; do not infer the unit independently in each chart component. [1]
Separate ordering from presentation
Parse accepted timestamps into a consistent internal representation, then sort by the represented instant. RFC 3339 describes conditions under which timestamp strings can be sorted directly, including consistent timezone representation and fractional precision. Mixed offsets should not be treated as naturally sortable text.
Format the resulting instant for the chosen display timezone and label that timezone near the chart. Changing the display zone should not silently regroup the provider’s candles. If your application builds its own bars, define the session calendar and interval boundaries separately from the axis labels. [1]
Keep a small set of boundary fixtures
We recommend fixtures containing two representations of the same instant, a missing offset, an invalid date, and a numeric timestamp in the wrong unit. Decide whether each input is accepted, rejected, or flagged. Make that policy consistent across storage, charts, and exports.
Add observations immediately before and after an interval boundary and a timestamp unexpectedly in the future. If the display uses a region with daylight-saving changes, test that transition too. Preserve enough source context to investigate anomalies without logging credentials or complete request payloads.
References
Primary sources for the technical details in this article. Implementation suggestions are our own.