Come usare il convertitore di timestamp Unix
Un timestamp Unix è il numero di secondi trascorsi dalle 00:00:00 UTC del 1º gennaio 1970, senza contare i secondi intercalari. È il modo più universale con cui i computer rappresentano il tempo, perché un singolo intero fissa un istante esatto a prescindere da fuso orario e formato della data.
Perché esistono sia secondi sia millisecondi
I sistemi più vecchi (Unix, time() di PHP e Python, UNIX_TIMESTAMP() di MySQL) usano i secondi, cioè 10 cifre. Date.now() di JavaScript, System.currentTimeMillis() di Java e la maggior parte dei framework mobili e frontend usano i millisecondi, cioè 13 cifre.
Mescolarli è una delle cause più frequenti di bug nello sviluppo: un valore di 13 cifre in millisecondi inviato a un backend che si aspetta secondi porta la data decine di migliaia di anni nel futuro; un valore di 10 cifre in secondi letto sul frontend come millisecondi riporta la data al 1970. Questo strumento riconosce l'unità dal numero di cifre e mostra entrambe, così non cadi nella trappola.
Timestamp e fusi orari
Ecco il punto chiave: un timestamp non ha fuso orario. È un istante assoluto. Lo stesso timestamp indica lo stesso momento ovunque nel mondo. I fusi orari entrano in gioco solo quando si converte il timestamp in una stringa di data leggibile.
Quindi lo stesso valore 1750000000 appare come un certo pomeriggio in UTC+8, come un'ora più mattutina dello stesso giorno in UTC e come il giorno precedente a New York — ma sulla linea del tempo sono uno stesso punto. Lo strumento mostra UTC, ora di Pechino (UTC+8) e la tua ora locale affiancate, il che rende molto più semplice il debug tra fusi orari.
Casi d'uso comuni
- Debug delle API: vedere a colpo d'occhio quando era davvero
createdAt: 1750000000dal backend - Analisi dei log: convertire i timestamp di un log in orari leggibili e restringere il momento del guasto
- Query al database: costruire condizioni come
WHERE created_at > 1750000000 - Cache e firme: calcolare la scadenza di un token o verificare se il timestamp di una richiesta cade nella finestra valida
Il problema del 2038
Un intero con segno a 32 bit arriva a 2147483647, che corrisponde alle 03:14:07 UTC del 19 gennaio 2038. Oltre quel momento i sistemi più vecchi che memorizzano timestamp al secondo su 32 bit vanno in overflow. I sistemi moderni usano di norma interi a 64 bit, che arrivano a circa 292 miliardi di anni, quindi il problema non li riguarda. Il valore 2000000000 nella tabella qui sopra serve proprio a osservare quell'intervallo critico.
Domande frequenti
Posso inserire sia valori a 10 sia a 13 cifre?
Sì. Lo strumento decide dal numero di cifre: fino a 10 cifre sono secondi, da 11 a 13 sono millisecondi, e mostra sempre entrambe le unità per il confronto.
Perché l'orario convertito differisce di 8 ore da quanto mi aspettavo?
Di solito significa che stai confrontando UTC con l'ora di Pechino. Un timestamp è assoluto; UTC lo esprime nel fuso a offset zero. L'ora di Pechino è UTC+8, quindi per lo stesso timestamp si legge 8 ore più tardi. Lo strumento li mostra entrambi, e il confronto affiancato toglie la confusione.
In quale fuso orario viene interpretata la data quando la converto?
Nel tuo fuso orario locale, che è quanto si aspetta la maggior parte degli scenari di sviluppo. Se il tuo input è inteso come UTC, correggi tu il numero oppure aggiungi 8 ore al risultato (per l'ora di Pechino).
Quali formati di data sono supportati?
2026-10-15 14:30:00, 2026/10/15 14:30, 2026-10-15T14:30:00Z e una data semplice 2026-10-15 (interpretata come 00:00:00 di quel giorno) vengono tutte riconosciute.