SEC EDGAR kabul zaman damgaları birçok şirket submissions dosyasında tam bir Eastern offset'i kadar kaymış durumda

Her zaman doğru olmayan bir UTC etiketi

SEC'nin submissions API'si her başvuru için bir acceptanceDateTime döndürüyor ve bunu UTC olduğunu belirten Z son ekiyle damgalıyor. dev.to'da yayımlanan bir analize göre bu etiket şirketlerin önemli bir bölümü için yanlış — ve yanlış olup olmaması başvurunun kendisine değil, hangi şirket dosyasını okuduğunuza bağlı.

Sonuçları, günün saatinin önemli olduğu her yerde kendini gösteriyor: kazanç bildirimlerinin açılış öncesinde mi yoksa kapanıştan sonra mı geldiğine karar vermek, bir içeriden kişinin alımını bir işlem gününe atamak veya bir olay çalışmasında sıfırıncı günü belirlemek gibi.

Ölçüm neyi kapsıyordu

Yazar, 11 Ekim 2026 tarihinde 25 şirketin submissions dosyasını örnekledi; her birinden en yeni 12 başvuruyu ve ABD standart saatinin temsil edildiği Aralık ile Şubat arasındaki altı eski başvuruyu aldı. Bu, 34 form türü, 98 başvuru aracısı ve üç yıla yayılan 450 başvuru ortaya çıkardı.

Her API zaman damgası, sec.gov'daki başvurunun index sayfasında yazan Accepted zamanıyla karşılaştırıldı; bu zaman ABD Eastern saatiyledir ve başvurunun kendi SGML başlığıyla eşleşir.

Her dosya dahili olarak tutarlı çıktı: ya tüm zaman damgaları doğruydu ya da tamamı tam olarak bir Eastern offset'i kadar kaymıştı — gün ışığı uygulaması sırasında kabul edilen başvurular için dört saat, standart zamanda beş saat. Form türü, başvuru aracısı veya günün saatinden bağımsız olarak başka hiçbir offset görülmedi.

Microsoft, Alphabet, Tesla ve Intel dahil 25 dosyadan 12'si doğruydu. Apple, Nvidia, Amazon, Meta, JPMorgan, Walmart, Berkshire Hathaway ve Palantir dahil 13'ü kaymıştı. Doğu saatiyle 06:30'da — 10:30 UTC — kabul edilen bir JPMorgan kazanç 8-K'sı API'de 14:30Z olarak görünüyor ve açılış zilinden önce değil sonra konumlanıyor.

Tek başvuru, iki cevap

Bir Form 4 hem ihraççının submissions dosyasında hem de içeriden kişinin kendi dosyasında bulunur; dolayısıyla aynı accession kendisiyle çelişebilir. 26 Şubat 2026'da Eastern saatiyle 18:34 ve 18:33'te kabul edilen iki Apple yönetim kurulu üyesi Form 4'ü, Apple'ın dosyasında 2026-02-27T04:34:19Z, yönetim kurulu üyesinin dosyasında ise 2026-02-26T23:34:19Z olarak görünüyor. Yönetim kurulu üyesinin dosyası doğru; Apple'ınki beş saat geride, yani standart zaman offset'i kadar.

Desen dosya yeniden oluşturmalara işaret ediyor

Bu ayrışma, dosyaların içindeki başvuruların yaşından ziyade her dosyanın en yeni başvurusunu takip ediyor. En yeni başvurusu 2 Ekim'de veya öncesinde kabul edilmiş her dosya doğruydu; en yeni başvurusu 5 Ekim'de veya sonrasında yer alan her dosya, Şubat kayıtları dahil, kaymıştı. Yazarın hipotezi, Ekim başından bu yana yeniden oluşturulan submissions dosyalarının ekstra offset'le yazıldığı; ancak API Last-Modified başlığı göndermediği için yeniden oluşturma zamanları doğrulanamıyor — gönderinin kendisinin de belirttiği gibi bu bir bulgu değil, hipotez.

Bu ilk gözlem değildi: edgartools GitHub deposundaki bir issue (dgunning/edgartools#1501) 8 Ekim'de Apple'ın dört saat geride kaldığını, 7 Ekim'de ise bazı dosyaların Eastern saatinin UTC etiketiyle döndürüldüğünü bildirmişti. dev.to yazarı ölçüm verilerini bu issue'ya katkı olarak sağladı.

Sorun sürerken geçici çözümler

Gönderi iki hafifletme öneriyor. Güvenilir olanı, kabul zamanını index sayfasından veya SGML başlığından okumak; bunun bedeli başvuru başına bir istektir. Daha ucuz olanı dosya başına tekdüzeliği kullanır: dosyanın kaymasını ölçmek için tek bir başvurunun index sayfası zamanını örnekleyin, sonra dosyadaki her zaman damgasından bu offset'i çıkarın. Gün ışığı ve standart zaman farklı offset'ler taşıdığından, farklı mevsimlerden iki başvuruyla kalibrasyon yapmak daha güvenlidir; ayrıca yeniden oluşturma bunu değiştirebileceği için dosya yeniden indirildiğinde kalibrasyonun tekrarlanması gerekir.

Yazarın kendi finans MCP sunucusu canli-mcp doğrudan etkilendi: kazanç takvimi zaten index sayfalarını okuyordu, ancak olay çalışması bir başvurunun 16:00 kapanışından önce gelip gelmediğine karar vermek için acceptanceDateTime kullanıyordu. Mevcut veriyle zarar küçüktü — 2025'ten beri 31 JPMorgan 8-K'sından biri ve 55 Nvidia içeriden satışından hiçbiri farklı bir güne kaymadı — yine de Eastern saatini UTC etiketiyle yayımlayan bir dosya, her kapanış sonrası açıklamayı kendi gününe iterdi. Araç artık her dosyayı iki ek istekle kalibrasyon yapıyor ve hangi düzeltmenin uygulandığını raporluyor.

Neden önemli

EDGAR'ın submissions API'si, piyasa verisi hatları, backtest'ler ve açıklama izleme sistemleri için yaygın bir üst kaynaktır ve acceptanceDateTime herhangi bir zamana duyarlı mantık için doğal alandır. Alan sessizce gerçek UTC ile tam bir Eastern offset'i kadar kaymış zamanları harman ediyorsa — ve bu karışım dosyalar yeniden oluşturuldukça değişiyorsa — piyasa saatleri çevresindeki eşik testleri güvenilmez hale gelir ve hata dış bir kontrol olmadan görünmez kalır. SEC alanı netleştirene veya düzeltenе kadar, tüketiciler ya başvuru başına doğrulama ya da dosya başına açık kalibrasyon yapmalı ve daha önce indirilmiş zaman damgalarına şüpheyle yaklaşmalıdır.