Reconciling Form 4 acceptance timestamps: submissions JSON versus SGML headers

[schneeball]

Hi,

How does EdgarTools reconcile acceptance timestamps from the submissions JSON with those in complete-submission SGML headers?

I maintain InsiderFilings.info. While validating our Form 4 database, we identified 288 stored timestamps that contained New York wall-clock values in a field our application interpreted as UTC. We corrected them individually against SEC submission headers, using America/New_York with the date-appropriate DST offset.

These were errors in our stored data. They do not, by themselves, establish an error in EdgarTools or in the current SEC JSON.

Three concrete examples

The following values come from our source checks dated 18 October 2026. All three are original Form 4 filings.

Accession | Header acceptance time, New York | UTC derived from header | Previous value in our database -- | -- | -- | -- 0001193125-26-057701 | 2026-02-18 19:18:28 | 2026-02-19 00:18:28Z | 2026-02-18 19:18:28 0001437749-25-031540 | 2025-10-22 18:15:16 | 2025-10-22 22:15:16Z | 2025-10-22 18:15:16 0001412100-25-000070 | 2025-05-28 08:32:51 | 2025-05-28 12:32:51Z | 2025-05-28 08:32:51

Complete SEC submissions:

• 0001193125-26-057701

• 0001437749-25-031540

• 0001412100-25-000070

To reproduce the comparison, locate <ACCEPTANCE-DATETIME> in each submission header and convert the New York wall-clock value to UTC. The first example also illustrates why the UTC calendar date can differ from the official filing date.

The conversion alone can be reproduced with Python 3.9+ and an available IANA timezone database:

from datetime import datetime, timezone
from zoneinfo import ZoneInfo
examples = [

("2026-02-18 19:18:28", "2026-02-19T00:18:28+00:00"),

("2025-10-22 18:15:16", "2025-10-22T22:15:16+00:00"),

("2025-05-28 08:32:51", "2025-05-28T12:32:51+00:00"),

]
for wall_clock, expected in examples:

eastern = datetime.fromisoformat(wall_clock).replace(

tzinfo=ZoneInfo("America/New_York")

)

actual = eastern.astimezone(timezone.utc).isoformat()

assert actual == expected, (wall_clock, actual, expected)

print(wall_clock, "New York ->", actual)

This snippet reproduces the timezone conversions; it does not download or validate the source documents.

My questions are:

1. Which source does EdgarTools use for acceptance time when both submissions JSON and SGML metadata are available?

2. Is there an existing reconciliation or validation path for disagreements between them, or a recommended way for users to perform that check?

I have not reproduced an EdgarTools bug and am asking about the recommended approach before drawing any library-specific conclusions. Current JSON responses may also differ from historical snapshots.

For context, our descriptive study documents the correction and validation procedure, with data and reproduction code:
https://insiderfilings.info/research/sec-form-4-timing/

Disclosure: I maintain the database and authored the study; its validation is internal. The study measures recorded acceptance, not first public availability or provider receipt.

[arhancanli]

Read from the code at main (2b92e2a), so this is what it does today:

1. Which source. Both are exposed and they are not merged. filing.acceptance_datetime on a filing from get_filings() / company.get_filings() comes from acceptanceDateTime in the submissions JSON (edgar/entity/data.py, parsed with fromisoformat(... 'Z' -> '+00:00'), so it is treated as UTC). filing.header.acceptance_datetime comes from the <ACCEPTANCE-DATETIME> line of the filing's own SGML header (edgar/headers.py, strptime('%Y%m%d%H%M%S')), which is naive Eastern time, not UTC. The EntityFiling docstring says the JSON value is "not reliably UTC" and recommends the header for a precise time (one extra request per filing).
2. Reconciliation. I could not find a built-in comparison of the two. The check is: take header.acceptance_datetime, attach America/New_York, convert to UTC, and compare with the JSON value. A mismatch of exactly the Eastern offset (4 h in EDT, 5 h in EST) means the JSON value was shifted by one extra offset.

Our own measurement agrees with the second point: on 2026-10-11 I compared 450 filings from 25 companies' submissions files against their headers. Within a file the result was uniform (every filing right, or every filing shifted by the Eastern offset), but the same filing read differently in two different files. So a per-file check is cheaper than a per-filing one, but the shift is not something to correct blindly: take the header as the reference. Write-up and method: #1501 (comment)

One caveat on your examples: the first row (19:18:28 ET on 2026-02-18) is on the 19th in UTC, so any pipeline that stores UTC and then takes .date() will disagree with EDGAR's filing date by a day. Keep the filing date as its own field.

[schneeball]

Thanks, this answers my question. We retain the official filing date
separately; the UTC date rollover in the first example is expected.

I also read the later comments in #1501. The newly appended Form 4 with a
different offset from older entries in the same file is an important caveat
to per-file calibration. We’ll continue using the individual SGML headers
as our reference.

Thanks for pointing me to that discussion.