SEC EDGAR acceptance timestamps off by a full Eastern offset in many company submissions files

A UTC label that is not always true

The SEC's submissions API returns an acceptanceDateTime for every filing, stamped with a Z suffix that marks it as UTC. According to an analysis published on dev.to, that label is wrong for a large share of companies — and whether it is wrong depends on which company file you read, not on the filing itself.

The consequences land wherever time of day matters: deciding whether earnings arrived before the open or after the close, assigning an insider purchase to a trading day, or fixing day zero in an event study.

What the measurement covered

The author sampled 25 companies' submissions files on 11 October 2026, taking the 12 most recent filings from each plus six older filings from December through February so that US standard time was represented. That produced 450 filings spanning 34 form types, 98 filing agents and three years.

Each API timestamp was compared against the Accepted time printed on the filing's index page on sec.gov, which is expressed in US Eastern time and matches the filing's own SGML header.

Every file proved internally consistent: either all of its timestamps were correct, or all were shifted by exactly one Eastern offset — four hours for filings accepted during daylight time, five hours during standard time. No other offset appeared, whatever the form type, filing agent or time of day.

Twelve of the 25 files, including those of Microsoft, Alphabet, Tesla and Intel, were correct. Thirteen, including Apple, Nvidia, Amazon, Meta, JPMorgan, Walmart, Berkshire Hathaway and Palantir, were shifted. A JPMorgan earnings 8-K accepted at 06:30 Eastern — 10:30 UTC — surfaces in the API as 14:30Z, placing it after the opening bell rather than before it.

One filing, two answers

A Form 4 sits in both the issuer's submissions file and the insider's own file, so the same accession can contradict itself. Two Apple director Form 4s accepted on 26 February 2026 at 18:34 and 18:33 Eastern appear as 2026-02-27T04:34:19Z in Apple's file and 2026-02-26T23:34:19Z in the director's. The director's file is right; Apple's is five hours late, the standard-time offset.

The pattern points to file rebuilds

The split tracks each file's most recent filing rather than the age of the filings inside it. Every file whose newest filing was accepted on or before 2 October was correct; every file whose newest filing landed on or after 5 October was shifted, including its February entries. The author's hypothesis is that submissions files rebuilt since early October are written with the extra offset, but the API sends no Last-Modified header, so rebuild times cannot be confirmed — a hypothesis, not a finding, as the post itself notes.

This was not the first sighting: an issue on the edgartools GitHub repository (dgunning/edgartools#1501) reported Apple running four hours late on 8 October, and on 7 October some files returning Eastern time labelled as UTC. The dev.to author contributed the measurement data to that issue.

Workarounds while it persists

The post proposes two mitigations. The reliable one reads the acceptance time from the index page or SGML header, at the cost of one request per filing. The cheaper one exploits the per-file uniformity: sample a single filing's index-page time to measure the file's shift, then subtract that offset from every timestamp in the file. Calibrating on two filings from different seasons is safer, since daylight and standard time carry different offsets, and calibration must be repeated whenever a file is re-downloaded, because a rebuild can change it.

The author's own finance MCP server, canli-mcp, was bitten directly: its earnings calendar already read index pages, but its event study used acceptanceDateTime to decide whether a filing preceded the 16:00 close. With current data the damage was small — one of 31 JPMorgan 8-Ks since 2025 and none of 55 Nvidia insider sales moved to a different day — although a file publishing Eastern time under a UTC label would push every after-close release onto its own day. The tool now calibrates each file with two extra requests and reports which correction was applied.

Why it matters

EDGAR's submissions API is a common upstream for market-data pipelines, backtests and disclosure monitoring, and acceptanceDateTime is the natural field for any time-sensitive logic. If the field silently mixes true UTC with times shifted by a full Eastern offset — and the mix changes as files are rebuilt — threshold tests around market hours become unreliable, and the error is invisible without an external check. Until the SEC clarifies or corrects the field, consumers need either per-filing verification or explicit per-file calibration, and previously downloaded timestamps should be treated as suspect.