Convertitore timestamp UNIX: epoche, fusi orari e bug anno-57123

Un utente di una delle mie app Laravel SaaS una volta inviato via email per dire che la data di rinnovo dell'abbonamento sembrava "un po' generosa". La pagina di fatturazione gli diceva che il suo piano si sarebbe rinnovato il 25 aprile dell'anno 57123.

L'insetto mi ha messo imbarazzantemente a trovare perché ogni singolo pezzo era corretto. Il frontend React inviato Date.now()- che ritorna millisecondi- e il backend PHP sì date('Y-m-d', $timestamp), che si aspetta bis. alimentazione 1740470400000 in una funzione in attesa 1740470400 E atterri circa 55.000 anni nel futuro. Nessuna eccezione, nessun avviso, nessun test fallito. Solo un cliente che chiede educatamente se il suo abbonamento è durato davvero fino alla morte in calore della civiltà.

I timestamp sembrano l'argomento più noioso del software. Sono in realtà una delle fabbriche di bug più affidabili che abbiamo: secondi contro millisecondi, UTC vs Local, DST Transitions, il rollover 2038. la Convertitore di timestamp su Toolz.dev esiste perché mi sono stancato di farlo new Date(x * 1000) in una console del browser quaranta volte al giorno. Questa guida copre ciò che controllo ora, nell'ordine lo controllo.

tl; dr: Un timestamp UNIX conta secondi dal 1970-01-01T00:00:00 UTC. 10 cifre = secondi, 13 cifre = millisecondi- mescolandoli si mettono le date 55.000 anni di pausa Store UTC, convertire solo per la visualizzazione, utilizzare i nomi delle zone IANA come Asia/Dhaka invece delle abbreviazioni. Incolla qualsiasi timestamp nel Convertitore di timestamp per ottenere ISO 8601, RFC 2822, locali e moduli UTC - esegue lato client, quindi timestamp fuori di JWTS E i registri di produzione non lasciano mai il tuo browser.

Che cos'è esattamente un timestamp UNIX?

Un timestamp unix (tempo epoca, tempo POSIX) è il numero di secondi trascorsi da quando 1 gennaio 1970, 00:00:00 UTC- il & quot; Unix epoch." It's un singolo intero, non ha fuso orario (it's sempre UTC per definizione), ed effettivamente ogni OS, linguaggio e database lo capisce Quell'ultima proprietà è il motivo per cui è sopravvissuta a cinque decenni: è l'unico formato temporale su cui nessuno discute.

Perché 1970? nessuna ragione profonda - era una data rotonda conveniente vicino a quando Unix era in costruzione ai Bell Labs, e la prima Unix contava il tempo in un numero intero a 32 bit La scelta arbitraria si fossilizzò in uno standard universale, che è molto Unix.

Alcuni punti di riferimento da riconoscere a vista:

Quella quarta fila è il mio esempio preferito per un sottile motivo: un sacco di pagine di tutorial 1740470400 Come "25 febbraio 2025, 12:00:00". In realtà è 08:00 UTC- qualcuno l'ha convertito nel proprio fuso orario locale una volta e da allora il valore sbagliato è stato copiato in giro Verifica i timestamp con uno strumento, non con un post sul blog Incluso questo.

Secondi o Millisecondi - Come lo dici?

contare le cifre. Per qualsiasi data nell'era corrente:

• 10 cifre (1740470400) - secondi. Convenzione Unix, maggior parte delle API, PHP's time(), Python time.time() (come un galleggiante), API di Stripe.
• 13 cifre (1740470400000) - millisecondi. JavaScript'S Date.now(), Java System.currentTimeMillis(), MongoDB Date.

Questa è la distinzione esatta che ha prodotto la mia data di rinnovo dell'anno-57123, quindi spiego le modalità di fallimento:

• MS interpretato come secondi → date ~55.000 anni nel avvenire
• Secondi interpretati come MS → Date in Gennaio 1970 (Tutto crolla entro ~ 3 settimane dall'epoca)

Se vedi una delle firme - date antiche o date assurde del lontano futuro - conosci il bug prima di leggere una riga di codice Il Convertitore di timestamp Rileva il conteggio delle cifre ed etichetta entrambe le interpretazioni, che regola l'argomento "è questo S o MS?" in due secondi.

Quali formati di data devi effettivamente conoscere?

Tre coprono quasi tutto ciò che tocca uno sviluppatore funzionante.

ISO 8601- lo standard internazionale e cosa dovresti emettere nelle API e nei registri:

2026-07-13T09:30:45Z          UTC ("Z" = Zulu)
2026-07-13T15:30:45+06:00     with timezone offset
2026-07-13T09:30:45.123Z      with milliseconds

La funzione Killer che nessuno menziona: ISO 8601 Strings Ordina lessicograficamente in ordine cronologico. sort Su un file di registro funziona. 02/25/2026i formati -style possono't farlo - e peggio, US MM/DD ed europeo DD/MM sono indistinguibili per dodici giorni al mese.

RFC 3339 (scherzo) - il profilo del protocollo Internet della norma ISO 8601. leggermente più severo; se la tua API emette 2026-07-13T09:30:45Z soddisfi entrambi. Questo è il formato su cui standardizzare.

RFC 2822 (Sun, 13 Jul 2026 09:30:45 +0000) - intestazioni di posta elettronica e HTTP, feed RSS Lo leggi più spesso di quanto lo scrivi.

I formati del database sono cugini ravvicinati: MySQL DATETIME è 2026-07-13 09:30:45 (iso con uno spazio), PostgreSQL timestamptz rendering 2026-07-13 09:30:45+00.

In che modo le lingue che utilizzo gestiscono i timestamp?

I tre della mia pila e la stranezza in ciascuno di essi mi sono costati personalmente tempo.

JavaScript (quello MS):

Math.floor(Date.now() / 1000)        // current Unix seconds — Date.now() is ms!
new Date(1740470400 * 1000)          // seconds → Date: multiply by 1000
date.toISOString()                   // "2025-02-25T08:00:00.000Z"
Date.parse('2026-07-13T09:30:45Z') / 1000   // ISO string → Unix seconds

Quirk: tutto è millisecondi e new Date(1740470400) Silentemente ti dà il 21 gennaio 1970 invece di febbraio 2025. Nessun errore. Questa asimmetria è il bug di timestamp più comune nello sviluppo web.

php (quello dei secondi):

time();                                   // current Unix seconds
date('Y-m-d H:i:s', 1740470400);          // "2025-02-25 08:00:00" (server TZ!)
strtotime('2026-07-13 09:30:45');         // string → timestamp
(new DateTime('@1740470400'))
    ->setTimezone(new DateTimeZone('Asia/Dhaka'))
    ->format(DateTime::ATOM);             // "2025-02-25T14:00:00+06:00"

stranezza: date() formati nel Server Fuso orario predefinito, quindi lo stesso codice stampa date diverse sulla tua macchina e in produzione. Inoltre, new DateTime('@1740470400') ignora qualsiasi fuso orario che passi al costruttore: il @ il modulo è sempre UTC; devi chiamare setTimezone() dopo. WordPress aggiunge il proprio livello: current_time('timestamp') Restituisce un falso "locale" timestamp offset dal tempo reale di Unix, che è esattamente pericoloso come sembra.

pitone:

import time, datetime
int(time.time())                                      # current Unix seconds
datetime.datetime.fromtimestamp(1740470400,
    tz=datetime.timezone.utc)                         # → aware datetime
dt.isoformat()                                        # "2025-02-25T08:00:00+00:00"

stranezza: fromtimestamp() senza tz= Restituisce un ingenuo datamete in ora locale. I datetime ingenui sono il bug del tempo Python: si confrontano e sottraggono felicemente l'uno contro l'altro fino al giorno in cui uno di loro ha superato un confine DST. Passa sempre tz=;UTILIZZ zoneinfo (stdlib dal 3.9) per zone denominate.

Come dovresti gestire i fusi orari senza perdere la testa?

Quattro regole, tutte apprese in modo fastidioso:

1. Memorizza UTC. sempre. timestamp unix o timestamptz nel database. Il fuso orario diventa solo un problema di visualizzazione.
2. Converti a livello di presentazione. l'utente a Dhaka vede +06:00, l'utente a Berlino vede +02:00, il database non vede nessuno dei due.
3. Usa i nomi IANA, non le abbreviazioni. Asia/Dhaka, America/New_York, Europe/Berlin. Le abbreviazioni sono ambigue - CST significa Stati Uniti centrali, ora standard cinese o ora standard di Cuba a seconda di chi e n. 39; legge - e abbreviazioni don' t codifica le regole DST. I nomi IANA lo fanno.
4. Mai logica del DST a mano rotolo. Le date dell'ora legale differiscono in base al paese, al cambiamento in base alla legislazione e ad alcuni luoghi (Arizona, Bangladesh, Giappone) non osservano affatto l'ora legale. Il database IANA TZ esiste perché è davvero difficile; usa la libreria che lo avvolge.

Il corollario della Regola 1: quando due sistemi non sono d'accordo su un tempo di evento, converti entrambi i valori in timestamp UTC e confronta gli interi. Gli argomenti su "ma si dice che le 15 qui si dissolvono all'istante.

Qual è il problema dell'Y2038 e dovrebbe interessarti?

Un numero intero con segno a 32 bit raggiunge il massimo 2,147,483,647. Come un timestamp UNIX, questo 19 gennaio 2038, 03:14:07 UTC. Un secondo dopo, il valore si avvolge in negativo - al 13 dicembre 1901.

Sembra lontano; è & #39; t, per due ragioni. Primo, it' è a circa 11,5 anni da quando scrivo questo - ben all'interno della durata di vita dei sistemi embedded, dei controller industriali e di quell'unico servizio legacy che nessuno vuole toccare Secondo, avvenire Le date hanno colpito il muro in anticipo: un sistema che calcola un programma di mutuo di 15 anni o un certificato di 20 anni scade il 2038 oggi. MySQL TIMESTAMP il tipo di colonna è la trappola classica: it' è limitato a 32 bit e può't memorizza le date oltre il 19-01-2038, mentre DATETIME nello stesso database va bene.

Sei al sicuro su 64 bit time_t (qualsiasi sistema operativo moderno), JavaScript (Float64 MS), Python (precisione arbitraria) e PostgreSQL. Sei a rischio su sistemi embedded a 32 bit, vecchi TIMESTAMP colonne e codice C che codificano int32_t per tempo. Il test è semplice: push 2147483648 (Uno oltre il limite) attraverso la tua pipeline e guarda cosa viene fuori. la Convertitore di timestamp Ti genererà felicemente i valori del test post-2038.

Dove vengono visualizzati i timestamp nel debug reale?

Scadenza JWT. i gettoni portano iat e exp Reclami come secondi UNIX:

{ "sub": "user_8241", "iat": 1783915890, "exp": 1783919490 }

"Perché questo utente è disconnesso?" viene risposto convertendo exp. decodifica il token in Decoder JWT e converti il reclamo: entrambi eseguono il lato client, il che è importante perché un token incollato è una credenziale live (il Guida alla privacy dei dati copre il motivo per cui mi rifiuto di inserire i token negli strumenti lato server).

Correlazione del registro. Un incidente, tre servizi, tre formati: NGINX Logs [13/Jul/2026:09:30:45 +0000], l'app registra ISO 8601, un lavoratore in coda registra secondi epoche grezze. La conversione di tutto in un formato è il passaggio zero della creazione di una sequenza temporale.

Integrazione API. Stripe invia "created": 1740470400 (secondi). invia un'API creata da JavaScript 1740470400000 (ms). Le API di Google inviano stringhe RFC 3339 Se le consumi tutte e tre, la conversione è & #39; t occasionale - it& #39; s costante Formattare i payload nel Formattatore JSON e convertire i campi interessanti.

query di data-intervallo. WHERE created_at >= 1752364800 AND created_at < 1752451200- è il giorno giusto? Converti entrambi i limiti e controlla, nell'UTC, prima di eseguire l'eliminazione. Correlati: il Calcolatore di differenza di data Per "Quanti giorni tra questi due?", il Convertitore di fusi orari per la matematica dell'incontro e il Cron Parser Per "Quando questo programma viene effettivamente attivato?".

Domande frequenti

Che cos'è un timestamp UNIX?

Il numero di secondi trascorsi dal 1 gennaio 1970, 00:00:00 UTC (l'epoca Unix), memorizzato come un singolo numero intero It's indipendente dal fuso orario per definizione - lo stesso istante è lo stesso numero ovunque sulla Terra - motivo per cui it' è il formato di interscambio standard tra sistemi operativi, lingue e database.

Perché alcuni timestamp hanno 10 cifre e altri 13?

10 cifre è secondi (convenzione UNIX standard, PHP, la maggior parte delle API); 13 cifre sono millisecondi (JavaScript&S Date.now(), Java). Dividi per 1.000 per passare da MS a secondi. Confondendo le due turni date o da ~55.000 anni nel futuro o tornando al gennaio 1970.

I timestamp UNIX possono rappresentare le date prima del 1970?

Sì, i valori negativi contano all'indietro a partire dall'epoca. -86400 è il 31 dicembre 1969. Un timestamp firmato a 32 bit risale al 13 dicembre 1901. Alcuni sistemi e API rifiutano timestamp negativi, quindi testa prima di fare affidamento su di essi.

Qual è il problema dell'Y2038?

Overflow di timestamp firmati a 32 bit a 2.147.483.647 - 19 gennaio 2038, 03:14:07 UTC - con chiusura a dicembre 1901. I moderni sistemi a 64 bit non sono interessati, ma i dispositivi incorporati a 32 bit, il codice C legacy e MySQL TIMESTAMP le colonne sono esposte. Il calcolo dei sistemi date del futuro lontano (mutuo, certificati) ha colpito il bug anni prima dell'arrivo del 2038.

Perché la mia data mostra gennaio 1970?

Un timestamp zero o quasi zero ha raggiunto il codice di formattazione: di solito un valore non inizializzato, un'analisi fallita che restituisce 0 o sono passati secondi dove erano previsti millisecondi. Una data del 1970 sullo schermo non è quasi mai un punto dati; it's un null che indossa un costume.

Devo memorizzare timestamp o stringhe datetime nel mio database?

Memorizza UTC in entrambi i casi: il tipo conta meno della disciplina del fuso orario. Gli interi Unix sono compatti, ordinano banalmente e schivano completamente l'analisi; timestamptz/DATETIME le colonne sono leggibili dall'uomo nei risultati delle query e nell'aritmetica delle date di supporto in SQL Ciò che non devi fare è archiviare gli orari locali senza offset: la perdita di dati di that' viene rilevata solo alla successiva transizione DST.

L'epoca è influenzata dai secondi bisaglie?

Praticamente, no. Il tempo Unix finge che i secondi intercalari non esistano & #39; t - ogni giorno è esattamente di 86.400 secondi, e i sistemi in genere sbavano o fanno un passo all'orologio quando si verifica un secondo intercalare Per il codice dell'applicazione questo non è un problema; conta solo in contesti di temporizzazione scientifica, dove viene invece utilizzato il tempo TAI o GPS.

È sicuro incollare timestamp dei registri di produzione in un convertitore online?

Un timestamp grezzo da solo rivela poco, ma i timestamp di solito viaggiano con ID di contesto: ID utente, affermazioni di token, righe di registro. IL Convertitore di timestamp Su Toolz.dev converte interamente nel tuo browser senza trasmettere dati, quindi incollare valori direttamente dai registri di produzione o JWTS non esporrà nulla.

Come faccio a convertire un timestamp UNIX in una data leggibile?

Incolla il numero in un convertitore e leggi l'UTC e i risultati locali, oppure fallo nel codice: new Date(ts * 1000).toISOString() In JavaScript, datetime.fromtimestamp(ts, tz=timezone.utc) In Pitone, date -u -d @ts su Linux. L'unica cosa da capire prima è se il tuo valore è in secondi o millisecondi: tutto il resto ne consegue.

Come ottengo l'attuale timestamp di Unix?

date +%s In una conchiglia, Math.floor(Date.now() / 1000) In JavaScript, int(time.time()) In Pitone, SELECT EXTRACT(EPOCH FROM NOW()) a Postgresql. Nota che JavaScript è quello dispari: Date.now() Restituisce millisecondi, quindi la divisione non è facoltativa.