CodeKitHubChe cos'è questo strumento?
Un timestamp Unix (detto anche "epoch time") è il numero di secondi trascorsi dal 1° gennaio 1970, alle 00:00:00 UTC. È il metodo standard con cui i computer memorizzano i momenti nel tempo: database, file di log, API e linguaggi di programmazione lo utilizzano tutti perché si tratta di un unico numero inequivocabile che non presenta confusione legata al fuso orario.
Esistono due tipi: i secondi (oggi composti da 10 cifre, ad esempio 1720500000) e i millisecondi (13 cifre, utilizzati da JavaScript e Java). Questo strumento rileva automaticamente quale dei due hai incollato.
Perché usarlo?
- Leggi immediatamente i timestamp dai log, dalle righe del database e dalle risposte delle API.
- Rileva automaticamente se si tratta di secondi o millisecondi — non c’è bisogno di tirare a indovinare.
- Visualizza contemporaneamente l'ora locale, l'UTC, il formato ISO 8601 e l'ora relativa ("3 ore fa").
- Converti in entrambe le direzioni: timestamp → data e data → timestamp.
- Orologio in tempo reale con l'epoca corrente per una rapida consultazione.
Come si usa
- Per decodificare: incolla un timestamp (ad esempio 1720500000) nella casella a sinistra e clicca su "Converti".
- Visualizza il risultato nel tuo fuso orario locale, in UTC, secondo lo standard ISO 8601 e come ora relativa.
- Per effettuare la conversione: seleziona una data e un'ora nella casella a destra e clicca su "Converti" per ottenere il relativo timestamp in secondi e millisecondi.
- Usa l'orologio in tempo reale in alto quando ti serve solo l'ora attuale.
Esempio
Input
1720500000Risultato
Local time: 7/9/2024, 1:20:00 PM
UTC time: Tue, 09 Jul 2024 05:20:00 GMT
ISO 8601: 2024-07-09T05:20:00.000ZUn valore di 10 cifre viene interpretato come secondi; un valore di 13 cifre come millisecondi.
Consigli pratici
- Risoluzione dei bug relativi all’“ora errata”: nel 90% dei casi si tratta di problemi di visualizzazione del fuso orario, non di timestamp errati. Confronta la riga relativa all’UTC con i log del tuo server (i server di solito registrano i dati in UTC) prima di modificare qualsiasi codice.
- Una data che corrisponde esattamente al 1970-01-01 indica che il timestamp era pari a 0 o mancante: un classico sintomo di valore nullo, non una data reale.
- Una data intorno al 1970 + qualche giorno di solito indica che da qualche parte i secondi sono stati interpretati come millisecondi; una data nell'anno 56.000+ indica il contrario.
- Nei fogli di calcolo: Excel conta i giorni a partire dal 1900, non i secondi a partire dal 1970. Per ottenere un timestamp in secondi, converti il valore utilizzando la formula =(A1/86400)+DATE(1970,1,1).
Scenari di utilizzo reali
Dove i timestamp si rivelano fondamentali nella pratica: lettura dei campi di scadenza nei JWT e nei token API (exp/iat sono secondi Unix), correlazione dell’ora di segnalazione di un bug da parte di un utente con le righe dei log del server, impostazione dei TTL della cache e delle finestre cron, e verifica se un certificato o un token è effettivamente scaduto. La riga relativa al tempo ("3 ore fa") rappresenta il controllo di validità più rapido per tutti questi casi.
Il debug dei token JWT è un'operazione abbastanza comune da meritare una spiegazione dettagliata: decodifica il payload del token con lo strumento Base64, quindi incolla qui il valore "exp" — otterrai così una risposta immediata alla domanda "questo token è scaduto e da quanto tempo?".
Perché il tempo Unix è stato progettato in questo modo
La scelta di memorizzare un unico numero incrementale a partire da un’epoca fissa (anziché una struttura anno/mese/giorno/ora) è stata una scelta deliberata all’insegna della semplicità: due timestamp possono essere confrontati o sottratti con semplici operazioni aritmetiche, senza bisogno di alcuna logica di calendario; ecco perché i database, i formati di log e praticamente la rappresentazione interna della data in ogni linguaggio di programmazione si basano su questo principio. Il costo di tale semplicità è esattamente ciò che questo strumento si propone di appianare: gli esseri umani non ragionano in termini di «secondi trascorsi dal 1970», quindi ogni timestamp deve essere convertito in una data del calendario prima di avere un senso per chi lo legge, e tale conversione deve tenere conto contemporaneamente del fuso orario, della precisione (secondi contro millisecondi) e del formato di visualizzazione.
→ Codificatore/Decodificatore Base64 · Calcolatrice dell'età
Domande frequenti
Come fa lo strumento a sapere se il mio timestamp è espresso in secondi o in millisecondi?
In base alla grandezza. I valori pari a 1.000.000.000.000 (1e12) o superiori vengono considerati come millisecondi; i valori inferiori come secondi. Le date attuali corrispondono a circa 1,7 miliardi di secondi e circa 1.700 miliardi di millisecondi, quindi i due intervalli non si sovrappongono per le date realistiche.
Perché il mio timestamp indica un'ora diversa da quella che mi aspettavo?
Fusi orari. Un timestamp è sempre basato sull'UTC; la riga "ora locale" lo converte nel fuso orario del tuo dispositivo. Confronta la riga UTC con quanto riportato nei log del tuo sistema di origine: molti server registrano i log in UTC.
Che cos’è il “problema del 2038”?
I sistemi che memorizzano i timestamp come interi a 32 bit con segno andranno in overflow il 19 gennaio 2038. I sistemi moderni utilizzano interi a 64 bit e non ne risentono. Questo strumento utilizza i numeri JavaScript, che gestiscono date ben oltre il 2038.
È possibile convertire i timestamp negativi?
Sì. I timestamp negativi indicano date precedenti al 1° gennaio 1970; ad esempio, -86400 corrisponde al 31 dicembre 1969.
L'epoca include i secondi intercalari?
No. Il tempo Unix parte dal presupposto che ogni giorno abbia esattamente 86.400 secondi e ignora i secondi intercalari: una semplificazione voluta che facilita i calcoli.