Contents Lesson 6 of 16

5 min read · practitioner

What moment does a bar's timestamp actually mark?

An intraday row says 13:30:00 and reports four prices. Does that mean prices at 13:30, or prices during the minute that started at 13:30, or the minute that ended there? Getting this wrong shifts your whole series by one bar, which is exactly enough to make a piece of analysis look prophetic.

The stamp is the start

Each intraday row carries three time fields: timestamp (UNIX seconds), gmtoffset, and datetime (a human-readable string). The timestamp marks the moment the bar opens. The row stamped 2026-07-20 13:30:00 covers 13:30:00.000 through 13:30:59.999: its open is the first eligible print inside that window and its close the last.

You can confirm the convention without trusting anybody. Apple's US session opens at 09:30 New York time, which on 20 July 2026 was 13:30 UTC. The 1-minute bar stamped 13:30 has volume 1,024,090; the next one, 13:31, has 230,752. The opening auction is four times the following minute and it lands in the 13:30 bar, not the 13:29 one. The stamp is the start.

Everything is UTC

gmtoffset comes back as 0 and datetime is rendered in UTC, not exchange local time. A US equity bar labelled 13:30:00 is 09:30 in New York. A XETRA bar labelled 07:00:00 is 09:00 in Berlin.

This has a consequence people discover in November. /exchange-details/US reports Open: 09:30:00 and OpenUTC: 13:30:00. The local time is fixed by exchange rule; the UTC offset moves with daylight saving. In January the same 09:30 opening is 14:30 UTC. Any code that hardcodes 13:30 as "the US open" is correct for about eight months a year.

Store and compare in UTC. Convert to the exchange's Timezone — America/New_York, Europe/Berlin — only when a human is going to read it.

A missing minute is not missing data

Request Apple 1-minute bars for 20 July 2026 from 08:00 to 14:00 UTC and you get 359 rows. The window contains 361 minute slots. Two are simply absent: the minutes beginning 09:24 and 09:33 UTC.

Those are 05:24 and 05:33 in New York — deep in the pre-market session, which per the v2 exchange schema runs from 04:00 local. A bar exists only if at least one trade printed in it. In a thin pre-market minute, sometimes none does, so there is no bar. Every one of the 361 slots from 13:30 onward, once the regular session opened, is present.

Two working consequences:

  • Do not index intraday arrays by position. bars[30] is not "thirty minutes in". Index by timestamp.
  • Do not treat a gap as an error. If your model needs a value for every slot, you fill it deliberately — carrying the previous close forward with zero volume is one honest convention — and you record that you did. Silently letting the gap collapse means every later bar shifts one place left.

The first bar of that day is stamped exactly 08:00:00 UTC, which is 04:00 New York — the pre-market open to the minute. The session boundary is visible in the data itself.

Which session are you even in?

Because pre-market and after-hours prints appear in intraday data, an intraday series covers a longer day than the daily bar summarising it. A daily open is the regular-session opening auction; the intraday series has bars four and a half hours before it. Comparing "the first intraday bar" to "the daily open" therefore compares two different events, and they will not match.

Which session you get depends on the interval, and nothing in the response says so. Asked for the whole UTC day of 25 September 2026, Apple's 1m, 15m and 30m bars ran from 08:00 to the evening session, 04:00 to 20:00 in New York. The 5m and 1h bars covered the regular session only, 13:30 to the 20:00 closing print, and the hourly bars were stamped on the half hour: 13:30, 14:30 and so on, then a separate bar at 20:00. Mix two intervals in one study and one of them has an extended session the other does not.

This is the mechanical face of the question when-markets-sleep asks: the closing bell is a rule about one session, not a statement that trading stopped.

Try it now

  1. Here are Apple's 1-minute bars from 13:27 to 13:34 UTC on 25 September 2026, from=1790342820&to=1790343240. Find the bar with the largest volume and convert its stamp to New York time. It should be the opening minute. The second table is a morning in 5-minute bars from another September day, for comparison.
Live API response: mda12 apple 1m open sept 25
Live API response: apple five minute bars
  1. Here is every row of a nine-minute window in the pre-market of the same day, 10:30 to 10:38 UTC. Count the rows and compare against the number of minute slots. List the missing timestamp and check what time of day it falls in, in New York.
Live API response: mda12 apple premarket gap sept 25
  1. Here is the same kind of request for a January date, 15 January 2026, 14:27 to 14:33 UTC. Note where the opening bar sits in UTC. If you expected 13:30, daylight saving has just taught you something cheaply.
Live API response: mda12 apple 1m open jan 15
  1. Here is the whole UTC day of 25 September 2026 three times, at 5m, 15m and 1h. Read the first and last stamp of each and convert them to New York time. Write down which intervals carry the pre-market and the evening, and what an hourly bar stamped 13:30 covers.
Live API response: mda4 aapl 5m session edges
Live API response: mda4 aapl 15m session edges
Live API response: mda4 aapl 1h session edges