EDGAR : le suffixe Z n'est pas toujours UTC

Ce qui se passe

Chaque dépôt listé par l'API submissions de la SEC (data.sec.gov/submissions/CIK##########.json) porte un champ acceptanceDateTime, du type 2026-07-14T14:30:38.000Z. Le Z annonce de l'UTC. Pour une partie des sociétés, c'est faux : l'heure est plus tardive de 4 h pour un dépôt accepté en heure d'été (EDT), de 5 h en heure d'hiver (EST). Aucun autre écart n'est apparu.

L'auteur du relevé, qui publie le serveur MCP financier canli-mcp, l'a mesuré le 11 octobre 2026 : 25 sociétés, 12 dépôts récents chacune plus 6 datant de décembre à février, soit 450 dépôts, 34 types de formulaires et 98 agents de dépôt. Référence : l'heure « Accepted » de la page d'index de chaque dépôt (…/{accession}-index.htm), en heure de New York, qui concorde avec l'en-tête SGML du dépôt.

Ce que la mesure montre

Un fichier est soit juste pour tous ses dépôts, soit décalé pour tous.

• Justes : MSFT, GOOGL, XOM, PFE, KO, TSLA, NFLX, INTC, GE, F, O, SPY.
• Décalés : AAPL, NVDA, AMZN, META, JPM, BAC, WMT, BRK, TSM, GME, PLTR, MRNA, Vanguard.

Le même formulaire 4 vit dans le fichier de l'entreprise et dans celui du dirigeant, et les deux ne disent pas la même heure. Deux formulaires de directeurs d'Apple, déposés le 26 février :

Le fichier du dirigeant est juste ; celui d'Apple est plus tardif de cinq heures (février est en heure d'hiver).

Le partage suit le dernier dépôt de chaque fichier : tous ceux dont le plus récent a été accepté au plus tard le 2 octobre sont justes, tous ceux dont le plus récent date du 5 octobre ou après sont décalés, février compris. L'auteur soupçonne des fichiers reconstruits début octobre ; l'API n'envoie pas d'en-tête Last-Modified, donc c'est une hypothèse, pas un constat. Un ticket d'edgartools (#1501) signalait Apple en retard de 4 h le 8 octobre, et, le 7 octobre, des fichiers qui donnaient l'heure de New York étiquetée UTC.

Pourquoi ça compte

Dès que l'heure de la journée décide de quelque chose : un résultat publié avant l'ouverture ou après la clôture, le jour de bourse d'un achat de dirigeant, le jour 0 d'une étude d'événement. Le 8-K de résultats de JPMorgan, accepté à 06:30 à New York (10:30 UTC), s'affiche à 14:30Z : après l'ouverture au lieu d'avant.

Chez l'auteur, l'effet est modeste : seuls les dépôts de l'après-midi basculent de l'autre côté de la clôture de 16:00, soit 1 des 31 8-K de JPMorgan depuis 2025 et aucune des 55 ventes d'initiés de NVIDIA. Un fichier qui donnerait l'heure de New York étiquetée UTC serait pire : chaque publication de résultats après la clôture serait rattachée à son propre jour.

Comment s'y prendre

1. Quand l'heure compte, la lire sur la page d'index ou dans l'en-tête SGML du dépôt : une requête par dépôt.
2. Sinon, mesurer l'écart du fichier sur un dépôt (un fichier est uniforme), puis corriger les autres. Calibrer sur deux dépôts de saisons différentes ; s'ils divergent, lire chaque dépôt à sa page d'index.
3. Refaire la mesure à chaque nouveau téléchargement du fichier : une reconstruction peut changer l'écart.

from datetime import datetime
from zoneinfo import ZoneInfo

NY = ZoneInfo("America/New_York")

def ecart_heures(api_iso: str, index_ny: str) -> int:
    """0 si le fichier est juste, 4 ou 5 s'il est décalé."""
    api = datetime.fromisoformat(api_iso.replace("Z", "+00:00"))
    vrai = datetime.strptime(index_ny, "%Y-%m-%d %H:%M:%S").replace(tzinfo=NY)
    return round((api - vrai).total_seconds() / 3600)

ecart_heures("2026-02-27T04:34:19.000Z", "2026-02-26 18:34:19")  # 5

Ce qu'on ne sait pas

• Un seul auteur, 25 sociétés, un jour de mesure.
• La source ne mentionne ni avis ni correctif de la SEC.
• L'auteur publie un outil concerné, canli-mcp : c'est dans l'étude d'événement de cet outil que l'écart l'a mordu, et il l'y a corrigé.

Source : The same SEC filing has two acceptance times, depending on which EDGAR file you read, DEV Community, octobre 2026.