Python e Postgres possono leggere CET con un’ora di differenza
Indagando un fuso rifiutato da Postgres, Mergify ha trovato quattro sigle che Python e database interpretavano con un’ora di scarto estivo, senza segnalare errori.
Che succede
A mezzogiorno del 15 luglio, CET può indicare le 10 UTC per Python e le 11 UTC per Postgres. Mergify ha trovato questa differenza indagando un guasto nelle finestre che sospendono temporaneamente l’integrazione delle modifiche al codice. L’analisi, pubblicata il 26 ottobre, racconta due problemi distinti.
A far scattare l’allarme era stato localtime: accettato dall’API Python, veniva rifiutato dal Postgres di produzione e faceva fallire le query. CET, EET, MET e WET erano più subdoli. Nella configurazione esaminata, Python li trattava come zone con ora legale; Postgres dava precedenza alla propria tabella delle abbreviazioni, con scarti UTC fissi. Entrambi accettavano il dato, poi calcolavano un orario diverso.
Nessuna finestra salvata usava quelle quattro sigle: lo slittamento non aveva colpito gli utenti. La correzione, integrata il 28 settembre, esclude sei nomi e verifica con un test che gli altri producano lo stesso istante in gennaio e luglio. Rimane un limite concreto: il database dei test non contiene tutti gli alias presenti in produzione.
Perché conta
Il guasto con localtime faceva rumore; la differenza su CET sarebbe rimasta silenziosa. Nel sistema di Mergify, una stessa finestra avrebbe potuto risultare già attiva per le protezioni e ancora futura per la coda di integrazione. Un’ora di disaccordo dentro la stessa applicazione, con entrambi i sistemi convinti di avere un fuso valido.
Leggi la fonte
mergify.comVuoi sapere di più su pillole come questa?
Nella stessa edizione
Entire ripensa la revisione del codice per il lavoro degli agenti
Python e Postgres possono leggere CET con un’ora di differenza
ThinkRail conserva le intenzioni del progetto accanto al codice
Supabase: «Read-only» dà all’agente anche le chiavi API, «Database Read» no
Prossima Pillola