- Spegnimento
- 22 agosto 2026 alle ore 11:28 UTC
- Autore
- kamo
- Impegno
- ec88120
Un messaggio diretto inviato alle 3:33 AM Pacific ha mostrato "10:33 AM" — l'UTC grezzo orologio, stampato come se fosse locale. Due difetti indipendenti, presenti insieme su quasi ogni superficie che mostra un tempo. Il paradiso. Ogni servizio Java memorizza i timestamp come LocalDateTime e li mette sul filo con toString(): "2026-08-22T10:33:12.345", senza alcun offset e No Z. Il valore è UTC, perché i baccelli sono, ma la stringa non lo dice — e ECMAScript legge una data-tempo senza offset come LOCAL. new Date() in a Los Il browser di Angeles è atterrato sette ore in ritardo, plausibilmente, silenziosamente, ovunque. THE RENDER. toLocaleTimeString() senza tempo Formati di uno nel BROWSER zona, un fatto sul portatile. Un membro il cui profilo dice Eastern lavorando da un hotel a Denver deve ancora leggere i loro registri in Oriente. usoFormatters() costruito ogni Intl. DateTimeFormat senza tempoZone affatto. app/lib/serverTime.ts è ora l'unico posto che entrambi sono stabiliti: parseServerDate / toServerDate / serverEpochMillis tratta una stringa senza offset come UTC e passa una zona-portare uno attraverso intoccato; formatoInZone e gli amici rendono in un zona esplicita; un nudo YYYY-MM-DD rimane il giorno che nomina invece di scorrere indietro uno per tutti ad ovest di Greenwich; zonedDayKey secchi da parte del membro giorno così un messaggio del Pacifico 18:00 smette di depositarsi sotto domani. La zona stessa è risolta SERVER-SIDE nel layout radice e portata da MemberTimezoneProvider, quindi SSR e il cliente concordano sul primo render piuttosto che capovolgere dopo l'idratazione. useFormatters() lo lega, e 175 componenti ora Prendila da lì. timezoneService viene sostituito e documentato come tale: esso leggi ***'s TZ, che PostAuth*****Il servizio si riempie dalla riga USERS piuttosto che il profilo del membro, quindi la cache in localStorage per sempre — ecco perché correggere un fuso orario del profilo sembrava non fare nulla fino a quando i dati del sito erano Liberato. Non solo cosmetico. Le ricevute di lettura della chat sono state confrontate con i timestamp del messaggio su due orologi diversi, e che il confronto decide se "inviare" o "rivoca l'attaccamento" è offerto. callbackUrgency e dueUrgency ha risposto "è questo dovuto oggi" sul calendario del browser; entrambi ora prendere la zona del membro, e i loro test lo chiamano piuttosto che a seconda di dove la suite funziona. E' collegato al test delle npm e non riesce a costruire. su un nuovo verificarsi di entrambi i difetti — compreso il Date.parse e Intl. DateTimeFormat ortografia. Un test non può catturarlo da solo: gli apparecchi ottengono costruito con ISOString(), che aggiunge la produzione Z non invia, quindi suite passa mentre l'app è ore fuori. Eccezioni genuine (una parete-clock il membro digitato, una data del calendario ancorata a mezzogiorno UTC) portare un serverTime-ok commento dicendo perché.