US Overnight Trading Data: 5 Questions to Answer Before Nasdaq Goes Near-24/5 on December 6
TickDB Research ·
One stock, one Friday night, three "latest prices" — and a $9,500 gap on a 10,000-share position. Nasdaq plans to move to near 23-hour trading on December 6. If your data stack can't answer five basic questions about overnight prices, your daily bars, returns, risk numbers and reconciliations will drift — silently.
What's inside, based on primary documents from Nasdaq, the SEC, DTCC and FINRA, plus my own snapshot tests on 30 US-listed symbols (including 9 China ADRs):
- A map of the new US trading day, in ET and in Asia time, before and after the November 1 clock change
- The five questions, one by one: where the money goes wrong, and why
- An eight-question checklist you can send straight to your data vendor
- Three runnable Python snippets
Three prices, one stock
Late on Friday, October 9 (23:55 ET — Saturday lunchtime in Hong Kong), I pulled a snapshot for Apple (AAPL). It returned three "latest prices" at once:
- $336.64 — Friday's regular-session close at 16:00 ET
- $336.05 — the last after-hours print at 19:59 ET
- $337.00 — the overnight price. It sounds like the freshest number, but it's the oldest: it froze at 04:00 ET Friday, when Thursday night's overnight session ended. There is no overnight session on Friday night, so by the time I looked, that price was about 20 hours old.
Less than a dollar apart — does it matter? Put a position on it:
| Price your dashboard or system picks up | Value of 10,000 shares | Daily change (prior close $340.42) |
|---|---|---|
| Regular close $336.64 | $3,366,400 | −1.11% |
| After-hours $336.05 | $3,360,500 | −1.28% |
| Overnight $337.00 | $3,370,000 | −1.00% |
Same stock, same night: valuations up to $9,500 apart and three different daily returns. None of the numbers is wrong. What's wrong is not knowing which one you're using.
Prices from my snapshot at 23:55 ET on October 9, 2026; valuations assume a hypothetical 10,000-share position.
Picking the wrong price is the cheap mistake. The expensive one is counting trades that no longer exist.
On August 5, 2024, overnight volume in US stocks spiked. Blue Ocean said it cancelled trades executed between 01:45 and 03:06 ET. Citing data from South Korea's Financial Supervisory Service, the Korea Times reported that the cancelled trades totaled about KRW 630 billion across roughly 90,000 accounts. Korean brokers then suspended their US daytime-trading services; 18 of them didn't resume until November 4, 2025 — almost 15 months later.
Problems like this are about to stop being niche. Nasdaq plans to open a new 21:00–04:00 ET session on December 6, 2026. From that day, a trade printed at 10 p.m. on a Monday will belong to Tuesday.
After December 6, the US trading "day" gets longer. Before an overnight price can feed your returns, valuations, risk and reconciliation, it has to pass five questions. Get any one wrong and the money is miscounted — and nothing throws an error.
The rest of this piece runs in three parts: why now → the five questions → what to do. If you don't write code, read each section up to "Ask your vendor" and hand the technical notes to your engineers.
Part 1 — Why now: the exchange trading day is set to grow from 16 to nearly 23 hours
One day, five sessions — and two different starts for "overnight"
In many data systems, the US trading day still has three parts: pre-market, regular and after-hours, 04:00 to 20:00 ET — 16 hours in total.
Overnight trading, though, is already here. Blue Ocean, an alternative trading system (ATS), runs a session from 20:00 to 04:00 ET, Sunday through Thursday, according to its FAQ. Nasdaq plans to add a 21:00–04:00 ET session from December 6, and NYSE Arca, 24X National Exchange and Cboe EDGX have all announced overnight plans.
So the day now has five parts, and "overnight" starts at two different times: 20:00 on ATSs and 21:00 on exchanges. The hour in between is the pause window for the SIP — the consolidated US market data feed.
| Session | ET | Asia time, UTC+8 (before → after Nov 1) | Status |
|---|---|---|---|
| Pre-market | 04:00–09:30 | 16:00–21:30 → 17:00–22:30 | Live |
| Regular | 09:30–16:00 | 21:30–04:00 → 22:30–05:00 | Live |
| After-hours | 16:00–20:00 | 04:00–08:00 → 05:00–09:00 | Live |
| ATS overnight | 20:00–04:00 | 08:00–16:00 → 09:00–17:00 | Live |
| SIP pause | 20:00–21:00, Mon–Thu | — → 09:00–10:00 | From Dec 6 |
| Exchange overnight | 21:00–04:00 | — → 10:00–17:00 | From Dec 6 (planned) |
The first four sessions are already in your data. The last two begin on December 6, after US daylight saving time ends, so the "before Nov 1" column doesn't apply. Sources: Blue Ocean FAQ, Nasdaq notice ETA2026-46, SEC orders 34-105779 and 34-105780; Asia times converted by the author.
"Overnight" is not one session. It's several venues running several rule sets. Before you quote an "overnight price," say which venue and which window.
There's another way to read that table if your team, your users or your investors are in Asia:
The entire trading day in Shanghai (09:30–11:30, 13:00–15:00) and Hong Kong (09:30–12:00, 13:00–16:00) sits inside the US overnight session. While Asian desks are watching their home markets, US stocks are trading.
Dual-listed names make this concrete. In the same test, Alibaba's US ADR (BABA) had its overnight data stop at 16:00:00 Hong Kong time on October 9, while its Hong Kong shares (9988.HK) had a snapshot time of 16:08:08 — eight minutes apart.
Same company, different rules. BABA's name field reads "each represents eight Ordinary Shares," and the Hong Kong snapshot has no pre-market, after-hours or overnight objects at all. Currency, trade-date assignment, even what "one share" means — all different. (This is about rules, not a price comparison.)
Three dominoes: clearing has fallen; data and exchanges share one date
Extending US trading hours takes three dominoes: clearing, market data and the exchanges.
- Clearing — live. DTCC announced on June 29, 2026, that its subsidiary NSCC is now clearing 24×5, running continuously from Sunday 20:00 to Friday 20:00 ET.
- Market data — approved, planned for December 6. In June 2026, the SEC issued orders 34-105779 (CTA/CQ) and 34-105780 (UTP). The SIP will run from Sunday 21:00 to Friday 20:00 ET, pausing 20:00–21:00 Monday through Thursday, subject to industry readiness. Overnight trading will get a consolidated best quote and last-sale price for the first time; industry analysis puts the extra SIP data at roughly seven more hours a day.
- Exchanges — planned for December 6. In ETA2026-46 and the later ETA2026-56, Nasdaq said it plans to open a 21:00–04:00 ET session, aiming for nearly 23 hours a day, five days a week. Its FAQ notes that launch depends on SIP readiness and regulatory changes.
The date could still move. Risk.net reported in May 2026 that LSEG had not yet received final SIP specifications and that some participants expect a delay to early 2027, partly because of year-end code freezes. In the same report, Cboe, Nasdaq and NYSE said they remain confident in December 6.
The date may slip. The data problems won't. ATS overnight trading is running today, and its data is in your systems today. December 6 changes only the scale and the complexity.
Small volume, but closest to Asia
The obvious pushback: overnight volume is tiny — why bother?
NSCC says overnight activity is currently about 1% of its total volume. Small, yes. Unimportant, no. I took a sample of 30 symbols and divided overnight volume by daily volume:
| Group | Median | Range | Examples |
|---|---|---|---|
| China ADRs (9) | ~0.96% | 0.39%–3.30% | Li Auto 3.30%, Baidu 2.90%, Alibaba 2.65% |
| ETFs (6) | ~0.89% | 0.11%–1.56% | QQQ 1.29%, GLD 1.56% |
| Big Tech (10) | ~0.23% | 0.10%–0.69% | AAPL 0.21% |
| Small/mid caps (5) | ~0.07% | 0.05%–0.25% | LCID 0.05% |
The gaps between groups matter more than any single number: in this sample, the median overnight share for China ADRs was about four times that of Big Tech. My snapshot test on October 10, 2026 (Asia time). Overnight volume covers the session from the evening of October 8 to the early morning of October 9 ET; daily volume is for October 9. Different sessions — read for magnitude only, not as a market-wide figure.
In dollar terms, those 30 symbols traded about $720 million in that one overnight session — roughly $200 million in QQQ alone and about $35 million in BABA.
Where's the demand coming from? According to Blue Ocean's CEO, the venue averages about 130 million shares, or roughly $3.5 billion, a day, up from about 30 million shares a year earlier. South Korea's share of its business has fallen from about 65% to about 35% but remains its largest in Asia; the company has a Tokyo office and plans one in Hong Kong.
US overnight is Asia's working day.
A few dates worth adding to the calendar: Netflix (October 20) and Tesla (October 21) both report after the US close; the Fed meets October 27–28 and announces its decision on the 28th; Microsoft reports on October 28. Market reactions to all of these carry into after-hours and overnight trading — Asia's daytime. (Timing only, no view on direction.)
Bottom line: whether or not December 6 holds, overnight data is already in your stack — and teams covering China ADRs or serving users in Asia are closest to it. Next: the five places it can miscount your money.
Part 2 — The five questions: where the money goes wrong
Question 1: Which day does this trade belong to? One overnight trade can carry two dates
A trade's date isn't intrinsic — a rule assigns it. Different systems can date the same trade a day apart.
The scenario: A trade prints at 22:00 ET on a Monday. Do your daily bars, daily returns and position reports book it to Monday or Tuesday?
| Dating rule | Monday 22:00 ET trade goes to | Basis |
|---|---|---|
| TRF date | Monday | Calendar date of the actual execution time in ET |
| Blue Ocean session date (FIX Tag 75) | Tuesday | A session that crosses midnight is dated by the day it ends |
| Nasdaq (from Dec 6, planned) | Tuesday | Trades from 21:00 to midnight belong to the next trading day |
| SIP processing boundary | Tuesday | A day runs from 20:00 the prior day to 20:00 |
The TRF date and the session date differ by a day — not because anyone is wrong, but because the rules differ. Sources: Blue Ocean FAQ, Nasdaq ETA2026-46, SEC 34-105779; checked October 10, 2026.
How the money goes wrong: The 30 symbols above traded about $720 million in one overnight session. Whether that lands on Monday or Tuesday decides two days' worth of volume, returns and P&L. Shift the date and your daily returns, reports and reconciliations all shift with it. Nothing breaks visibly: the series looks continuous; the date labels just don't match your trading system.
Ask your vendor: "Is the date you return the TRF date, the session date, or the SIP processing boundary?"
For your engineers: Store both the source's date field and your own computed session date; never overwrite one with the other. Make the daily-bar rule an explicit config and never mix rules within one metric. Merge regular and half trading days in your calendar: the trading-calendar endpoint I tested lists November 27 (a half day) in a separate half_trade_days array and leaves out November 26 (Thanksgiving). Skip the half days and your date assignment breaks again.
Question 2: Which "latest price" is it? The overnight price you see on a weekend is the oldest of the three
A price in a field doesn't mean a trade just happened. Judge freshness by each price's own timestamp.
The scenario: I checked all 30 symbols. Every one returned overnight data with a non-empty price — and every overnight timestamp was the same moment: 04:00 ET on October 9, about 20 hours before my query. In the same responses, pre-market prices stopped around 09:30, after-hours prices around 19:59 and the regular session at 16:00. Each session's price freezes at the last moment of its own window.
How the money goes wrong: As the opening table showed, the same stock on the same night can put a 10,000-share position $9,500 apart. Pick the wrong price on a dashboard and users see the wrong P&L; pick it in risk and your stop sits in the wrong place.
Why: Official closing prices, fund NAVs and index rebalances are still anchored to the 09:30 open and 16:00 close (per FactSet's analysis; Nasdaq's FAQ also says the opening and closing auctions keep their official pricing role). However fresh an overnight price looks, it isn't the official price. And a single quote record often carries several sessions at once — read only one "latest price" field and you mix them up.
Ask your vendor: "Is the timestamp on the overnight price the time of the last trade, or the time the session ended?"
For your engineers: Take price, volume and time from the same session object, and judge freshness by that object's own timestamp. Snippet 2 in Part 3 does exactly this.
Question 3: Which venue did the price come from? When two feeds disagree, check the venue before blaming the data
If two feeds show different overnight prices, they may simply be quoting different venues.
The scenario: You run two data feeds. At the same moment overnight, their prices disagree. Which one do you suspect?
How the money goes wrong: Here the cost is people and time. You can lose a day chasing a "data error" that turns out to be two venues — or worse, write one ATS's price into a reconciliation file as "the US overnight price."
Why: Overnight trading today happens mainly on ATSs such as Blue Ocean; exchanges such as Nasdaq plan to join from December 6. FINRA's risk disclosure states that extended-hours trading can mean lower liquidity, higher volatility and wider spreads, and that prices shown on different systems may differ. FactSet adds that until the SIP upgrade there is no consolidated tape after hours, and ATS trades sit outside it. Until consolidated data covers overnight, reconciling one venue's price against another's doesn't hold up.
Ask your vendor: "Which venue does this overnight price come from — a specific ATS, an exchange, or consolidated data?"
For your engineers: Tag every overnight price with its source venue and don't compare prices across venues directly. After December 6, if you need consolidated data, confirm the SIP actually covers that window first.
Question 4: Does the trade still count? Overnight trades can be cancelled
Your data layer has to handle "it traded — and then it didn't."
The scenario: August 5, 2024, from the opening: overnight trades in about 90,000 accounts were cancelled, worth about KRW 630 billion.
How the money goes wrong: If your pipeline only ever adds and ignores cancellation messages, a trade that no longer exists stays in your volume, your VWAP (volume-weighted average price) and your signals — and flows on into returns, risk and reconciliation.
Why: Late reports, cancellations and corrections all change the result, and cumulative volume resets between sessions; without correction messages, any aggregate is provisional. Deduplication has a trap too: two genuine trades can share the same time, price and size. Deduplicate on stable event IDs or sequence numbers.
Ask your vendor: "How do you send cancellations and corrections? Can I see in the data that a trade was cancelled?"
For your engineers: Distinguish new, cancel and correct messages, and make aggregates reversible. If the vendor sends no corrections, label the affected figures "provisional."
Question 5: Is the clock hard-coded? From November 1, overnight shifts an hour later in Asia
ET is not a fixed offset from Asia time. When daylight saving ends, everything pinned to local time drifts by an hour.
The scenario: You schedule a job at 08:05 Hong Kong time to grab "just after the overnight open" data. Before November 1, ATS overnight trading starts at 08:00 HKT and the job works. After November 1, overnight starts at 09:00 HKT and the job fires before the open.
How the money goes wrong: Scheduled jobs, dashboard refreshes and on-call rotas all run an hour off — and you blame the data feed.
Why: US daylight saving time ends on November 1, 2026, and ET moves from 12 to 13 hours behind UTC+8. For example, 21:00 ET on October 30 is 09:00 on October 31 in Hong Kong; 21:00 ET on November 2 is 10:00 on November 3.
Ask your vendor: "Are your timestamps UTC, or local time with a time zone?"
For your engineers: Store raw times in UTC, split sessions in America/New_York, use half-open intervals, and drive everything from a trading calendar (no overnight session on weekends or holidays). I ran 13 boundary cases against the trading calendar and all behaved as expected, for example:
- Friday 21:00 → closed (Saturday isn't a trading day)
- Thanksgiving eve (November 25) 21:00 → closed
- Thanksgiving night (November 26) 21:00 → overnight, session date November 27
- 20:30 under Nasdaq rules → pause window
- 20:00 under ATS rules → overnight; session date is the next day, calendar date is the same day
For risk teams: four reasons a price stops updating
Price deviations go to a review queue. "No new price" is the easier one to misread.
A price far from the close is not an automatic alarm. Under Nasdaq's plan, its overnight session will have a price band from December 6: orders more than 20% above or below the reference price are rejected, with a minimum band width of $3 (stocks at $1 or more) or $1 (below $1). That band is where the exchange rejects orders — not your alert threshold.
"No new price" is harder. It can look identical in the data for very different reasons:
- Holiday: e.g. Thanksgiving, November 26. Under Nasdaq's rules, the evening of a Monday–Thursday market holiday can open the next trading day's overnight session at 21:00.
- Pause window: from December 6, the SIP pauses 20:00–21:00 ET, Monday through Thursday.
- Halt: some corporate actions trigger halts, which Nasdaq flags with code "M1."
- Feed drop: the problem is your own connection.
- No trades: what's left after ruling out the above — the market is open; nobody is trading.
Ask your vendor: "How do halts, pause windows, holidays and no-trade periods each appear in your data?"
For your engineers: Rule out holidays and pause windows with the trading calendar and session labels first, then check halt flags; only what remains is "no trades." Tell "no update" from "feed drop" by checking connection state against other active symbols, so you don't mistake a quiet market for a broken connection.
The five questions at a glance
| Question | Short answer | Ask your vendor |
|---|---|---|
| 1. Which day? | One trade can carry two dates | Which date do you return? |
| 2. Which latest price? | Check each price's own timestamp | Last trade time or session end? |
| 3. Which venue? | Check the venue before blaming the data | Which venue is this price from? |
| 4. Does it count? | Handle cancels and corrections | How are cancellations sent? |
| 5. Hard-coded clock? | Store UTC, split in ET | Are timestamps UTC? |
Part 3 — What to do before December 6
Every role has a different decision to make
| Role | Decide before December 6 |
|---|---|
| Executives | Does your current market data contract cover extended hours? How will you scale storage and processing (about seven extra hours of SIP data a day)? Who covers the overnight shift? Do you have a plan B in case of delay? |
| Product managers | Which "latest price" does the dashboard show? Do overnight prices carry a visible timestamp? Show stale values or blanks outside the overnight window? |
| Quants and researchers | Which dating rule do daily bars use? Which close do returns use? Does the backtest calendar include half days and holiday eves? |
| Risk | How are overnight price deviations reviewed? How do cancellations and corrections reach monitoring? How do you tell holidays, pauses, halts and no-trade periods apart? |
| Procurement / vendor management | Can the vendor explain its dating rules and source venues? How precisely does the contract define session coverage? Can unanswered items go into production? |
Find your row — each line is a decision, not a fact to memorize. Based on Nasdaq ETA2026-46, SEC 34-105779 / 34-105780, DTCC's press release and Risk.net reporting; checked October 10, 2026.
The item executives most often miss is the plan B. December 6 may hold or slip; planning for a delay isn't pessimism — it keeps your data stack from needing a rebuild when the date moves.
Then there's build-versus-buy. A homegrown, session-aware data layer means maintaining, indefinitely:
- Two overnight start times (20:00 and 21:00) plus the SIP's 20:00 day boundary
- A trading calendar that handles holiday eves and half days
- Two daylight-saving switches a year
- Cancellation and correction messages
- Separate timestamps and volumes for every session
- Rules and venues that will keep changing after December 6
This isn't code you write once. The rules are still moving, venues are still being added, and the date may still slip — someone has to track every change.
Eight questions for your data vendor — no clear answer, no production
"Covers US equities" in a contract doesn't tell you how overnight is handled. Copy these eight questions into your next vendor email:
| Area | What to ask | Risk if unanswered |
|---|---|---|
| Symbol coverage | Which symbols have overnight data — all US stocks, or a subset? | You assume full coverage; some symbols have none |
| Overnight start and holidays | Does overnight start at 20:00 or 21:00? How are holiday eves handled? | Trades booked to the wrong day; gaps around holidays |
| Dating rules | Is the date you return the TRF date, the session date, or the SIP processing boundary? | Daily bars, returns and reconciliations shift by a day |
| Source venue | Which ATS or exchange does the overnight price come from — or is it consolidated? | Cross-venue reconciliation sends you down the wrong path |
| Snapshot or tick | Snapshot or trade-by-trade? What moment does the timestamp represent? | Stale values treated as live |
| Cancels and corrections | How are cancellations and corrections sent? Can I see a cancelled trade? | Volume, VWAP and signals keep cancelled trades |
| Outside the overnight window | Stale value, blank, or nothing returned? | Missing data treated as zero volume; coverage overstated |
| Contract scope | Does the current contract cover extended hours? How is extra volume priced? | You discover the gap after go-live |
Any row without a clear answer is a risk. You don't need "yes" to everything — you need a clear answer to everything. Based on FINRA's extended-hours risk disclosure, Blue Ocean's FAQ, Nasdaq ETA2026-46 and SEC 34-105779 / 34-105780.
For acceptance testing, use a simple coverage measure: let U be the set of symbols you expect to have overnight data and V the set that passes your checks; coverage = |U ∩ V| ÷ |U|. With no reliable expected list, report coverage as "not computable" — never default to 100%.
Three snippets to build sessions, dates and freshness into your pipeline
This section is for your engineers.
TickDB provides a unified global market data API for developers and AI applications, giving teams real-time and historical data across major markets — including US, Hong Kong and China A-shares — through a single integration, so they can ship market data, analytics and monitoring products faster.
I ran the checks above against TickDB's snapshot endpoint. The response's data field is a list; US pre-market, after-hours and overnight data live in three separate objects: pre_market_quote, post_market_quote and overnight_quote. The overnight object's fields are last_done (string), timestamp (13-digit milliseconds, integer), volume (integer), quote_volume (string), high, low and prev_close. There is no top-level session field, so you can't tell a record's session from the top level alone.
| What it does / where it stops | How to verify |
|---|---|
| Pre-market, after-hours and overnight data come as three separate objects, each with its own timestamp | Pull a US snapshot on a weekend and compare the three timestamps |
| US overnight data and Hong Kong stocks use the same snapshot endpoint | Query BABA.US and 9988.HK and compare timestamps |
| Limit: in this test, all 30 overnight timestamps were exactly 04:00:00.000 ET — even for LCID, which traded only 3,324 shares that night (pre-market and after-hours timestamps varied). The overnight timestamp looks like the session end, not the last trade | Fine for judging freshness; confirm with the vendor before inferring last-trade time |
| Limit: the documentation doesn't say which venue overnight data comes from; this piece tested the snapshot endpoint only | — |
The first two rows are what this test shows; the last two are its limits. Don't infer full market or full-session completeness, or best-price quality, from this table. My tests on October 10, 2026, covering AAPL, BABA.US, 9988.HK and about 30 other symbols.
What changes if you do this: skip it, and daily bars shift by a day, engineers chase failures that don't exist, and wrong dates flow into returns, risk and reconciliation. Do it, and snippet 2 judges freshness by each object's own timestamp, snippet 3 writes session labels and session dates into your signal layer, and the eight vendor questions hold every provider to the same standard.
One example: a product manager running a China ADR dashboard checks it at 11 p.m. Hong Kong time on a weekday — US regular trading is underway — runs snippet 2, and finds the "overnight price" still stuck at 4 p.m., nearly eight hours old. The label becomes "Overnight (as of 16:00)." This comes from a test at 23:48 HKT on October 9, 2026: the overnight object had stopped at 16:00 HKT, about 7.8 hours behind the top-level timestamp.
Snippet 1: Pull a US snapshot and check both the HTTP status and the API's own return code
import os
import requests
API_KEY = os.environ["TICKDB_API_KEY"] # never hard-code your key
resp = requests.get(
"https://api.tickdb.ai/v1/market/ticker",
params={"symbols": "AAPL.US,MSFT.US,NVDA.US", "type": "stock"}, # max 50 per request
headers={"X-API-Key": API_KEY},
timeout=10,
)
resp.raise_for_status()
body = resp.json()
if body.get("code") != 0:
raise RuntimeError(f"API error: {body}")
items = body.get("data") or []
Snippet 2: Tell "missing," "empty" and "zero" apart, and compute how old the overnight data is
import time
OVERNIGHT_FIELDS = {"price": "last_done", "time": "timestamp", "volume": "volume"}
def read_field(obj, key):
if not isinstance(obj, dict) or key not in obj:
return "MISSING", None
value = obj[key]
if value is None or value == "":
return "EMPTY", None
try:
if float(value) == 0: # last_done is a string; volume is an integer
return "ZERO", value
except (TypeError, ValueError):
return "INVALID", value
return "VALUE", value
def age_hours(obj, now_ms):
state, ts = read_field(obj, "timestamp")
return round((now_ms - ts) / 3_600_000, 1) if state == "VALUE" else None
now_ms = int(time.time() * 1000)
for item in items:
overnight = item.get("overnight_quote")
for name, key in OVERNIGHT_FIELDS.items():
print(item.get("symbol"), name, *read_field(overnight, key))
print(item.get("symbol"), "overnight data age (hours):", age_hours(overnight, now_ms))
Snippet 3: Label sessions by venue and return both the session date and the calendar date
from datetime import datetime, time, timedelta, timezone
from zoneinfo import ZoneInfo
NY = ZoneInfo("America/New_York")
# Overnight starts at different times by venue: ATSs typically 20:00, Nasdaq (planned) 21:00
VENUE_OVERNIGHT_START = {"ATS_2000": time(20, 0), "NASDAQ_2100": time(21, 0)}
def label(ts_ms, venue, trading_days):
"""Return (session, session_date, calendar_date).
trading_days: set of dates from the exchange calendar (merge regular and half days).
Early closes on half days are not handled; add that before production use."""
t = datetime.fromtimestamp(ts_ms / 1000, tz=timezone.utc).astimezone(NY)
c, d = t.time(), t.date()
if c >= VENUE_OVERNIGHT_START[venue]:
nd = d + timedelta(days=1) # the evening portion belongs to the next calendar day's session
return ("OVERNIGHT", nd, d) if nd in trading_days else ("CLOSED", None, d)
if d not in trading_days:
return ("CLOSED", None, d)
if c < time(4, 0):
return ("OVERNIGHT", d, d)
if c < time(9, 30):
return ("PRE", d, d)
if c < time(16, 0):
return ("REGULAR", d, d)
if c < time(20, 0):
return ("POST", d, d)
return ("GAP", None, d) # e.g. the 20:00–21:00 pause under Nasdaq rules
These snippets check integration-layer behavior only. Results describe the calls made, not market-wide or full-session completeness, and say nothing about best price. Snippet 3 is an illustration, not an official algorithm for exchanges, the SIP, TRFs or ATSs.
FAQ
1. What are US overnight trading hours?
ATS overnight trading runs 20:00–04:00 ET (08:00–16:00 in Hong Kong before November 1; 09:00–17:00 after). Nasdaq's planned session runs 21:00–04:00 ET — 10:00–17:00 in Hong Kong from December 6. Check each venue's rules for specifics.
2. Will US stocks trade 24 hours a day after December 6?
No. Nasdaq is planning near 23-hour trading, five days a week: the SIP pauses 20:00–21:00 ET Monday through Thursday, and there's no weekend trading. Launch depends on SIP readiness and regulatory changes.
3. Which day does an overnight trade belong to?
It depends on the rule. Nasdaq plans to assign trades from 21:00 to midnight to the next trading day; the TRF date follows the actual execution time in ET; Blue Ocean's session date follows the day the session ends; the SIP's processing day runs from 20:00 the prior day to 20:00.
4. Can I use the overnight price as the closing price?
Not recommended. Official closes, fund NAVs and index rebalances are still anchored to the 16:00 ET close. Overnight prices may come from different venues, with lower liquidity and wider spreads, and different systems can show different prices.
5. What should I ask a vendor before buying US overnight data?
Six things: dating rules, source venues, snapshot or tick, how cancellations and corrections are handled, what's returned outside the overnight window, and whether the contract covers extended hours. If they can't answer clearly, it doesn't go into production.
One last question
December 6 may slip. But "what counts as a trading day" will never be as simple as it was.
Where does your team cut its daily bars today?
One thing you can do this week: on a weekday, pull a US snapshot from your data provider twice — once during Asian business hours and once during US regular hours — and check which moment each "overnight price" timestamp actually points to.
References
All accessed October 9–10, 2026.
- Nasdaq Trader, ETA2026-46 and ETA2026-56
- Nasdaq, 23/5 Trading FAQ
- SEC, Release Nos. 34-105779 (CTA/CQ) and 34-105780 (UTP)
- DTCC, press release on NSCC extended clearing hours (June 29, 2026)
- Blue Ocean, FAQ (operating hours; session date vs. TRF date around ex-dividend dates)
- FINRA, extended-hours trading risk disclosure
- FactSet, "24/5 Trading: What It Is, Why It's Coming, and What It Means for Your Data Stack"
- Risk.net, report on the 24-hour trading launch date (May 2026)
- Korea Times, reports of August 8, 2024 and November 4, 2025; Markets Media, August 2024
- Federal Reserve 2026 FOMC calendar; Netflix, Tesla and Microsoft investor relations pages
- TickDB, snapshot API documentation and author's test records