This is a data reliability story rather than a finance one, and I doubt the shape of it is unique to this source.
The SEC's submissions JSON at data.sec.gov gives every filing an acceptanceDateTime ending in "Z". For a large minority of companies that Z is wrong: the clock in the string is already New York time, not UTC. Read as UTC it puts the filing 4 or 5 hours later than it happened, which in my case was enough to move a row across the 16:00 market close and flip it from intraday to after hours.
So I stopped trusting the JSON and re-read the raw SGML header of each submission instead, where the field ACCEPTANCE-DATETIME is always Eastern, and compared the two record by record: 64,827 filings, every 8-K item 2.02 I could pull for 808 companies, 2003 to 2026. The gap between the two stamps is always exactly 0, 4 or 5 hours. No partial offsets, no noise, nothing in between.
What surprised me was the grain. It is not per record:
- 624 companies converted in every single one of their filings
- 181 in none of them
- 3 mixed, and each of those three differs in exactly one filing, its most recent
The unit is the entity, not the row. That is the difference between re-ingesting everything and building a small lookup table, because a handful of records per entity classifies it.
I want to flag how I got that wrong first, because the mistake is the reusable part. I had already published the opposite conclusion, per record, off a sample of 120 entities. The sample was internally clean and the rule it produced was false, because the counterexamples were entities I had not drawn. The fix was not a better test on the sample, it was counting how many cases would have to exist to break the rule and then going looking for them on purpose.
Two caveats worth being precise about.
I cannot find this field documented anywhere on the SEC's API or developer pages, so this is undocumented behaviour that is inconsistent with itself, not a broken contract. "The API lies" is a stronger claim than the evidence carries.
And the source repairs entries after the fact. Entities that came back unconverted last week come back converted now. Any snapshot is dated, mine is 2026-09-06, and the three mixed entities differing only in their newest filing is that same lag showing up as a fingerprint rather than as a contradiction. It is also why I am not naming a company as an example: a named example expires the moment the source touches that record, and then whoever checks it concludes the rest is wrong too. The method is the part that reproduces.
To check it against whatever you are pulling: take three or four records for one entity, read ACCEPTANCE-DATETIME out of the SGML header, and compare the wall clock against the JSON. If they match, the Z is decoration.
One more, independent of timezones, in case anyone is doing an event study off this field. The acceptance stamp is a ceiling, not the event. Allowing 15 minutes between the press release and acceptance, 8,756 of the 27,227 rows that look like they landed after the close were most likely intraday, about a third of them. The error only runs one way, so a correct time based split survives it, but it is not zero.