Convertitore di Timestamp Unix

Timestamp Unix senza mal di testa

Chiedi a tre sviluppatori che ora è e potresti ottenere tre risposte diverse, a seconda di dove si trovano. Chiedi a un timestamp Unix e ottieni esattamente un numero, lo stesso per tutti sul pianeta. Quel singolo intero è il motivo per cui l'epoch time costituisce silenziosamente la base di quasi ogni file di log, riga di database e risposta API che incontrerai. Questa pagina spiega cosa significa quel numero, come leggerlo in entrambe le direzioni e dove tende a fare brutti scherzi.

Cos'è davvero il tempo Unix

Un timestamp Unix è il numero di secondi trascorsi dalle 00:00:00 UTC del 1 gennaio 1970, senza contare i secondi intercalari. Quel momento è chiamato epoch, ed è stato scelto dai primi ingegneri Unix semplicemente perché era una data tonda comoda da cui contare. All'epoch il valore è esattamente 0. Ogni secondo da allora aggiunge uno, quindi il numero cresce soltanto. Le date precedenti al 1970 sono perfettamente valide, espresse come interi negativi.

Vedrai questo concetto anche come tempo POSIX o, in senso lato, epoch time. Qualunque sia l'etichetta, la meccanica è la stessa: un contatore di secondi sempre crescente. Poiché è un semplice intero piuttosto che una stringa formattata, un computer può memorizzarlo in pochi byte e confrontarne due con una singola sottrazione.

Secondi, millisecondi e varianti

Il tempo Unix classico conta secondi interi, il che produce il familiare numero a dieci cifre che vedi oggi. Ma molti ambienti hanno bisogno di una risoluzione più fine. JavaScript, ad esempio, lavora in millisecondi, producendo un valore a tredici cifre, e alcuni sistemi si spingono fino a microsecondi o nanosecondi. Una regola pratica affidabile: un numero a dieci cifre è in secondi, tredici cifre sono millisecondi. Se la data convertita finisce da qualche parte intorno al 1970 quando ti aspettavi il giorno corrente, quasi certamente hai passato millisecondi a un campo in secondi, o viceversa. Il nostro convertitore rileva automaticamente l'ordine di grandezza, così raramente devi indovinare.

Perché gli sviluppatori lo usano

Il grande vantaggio è che un timestamp è neutro rispetto al fuso orario. L'intero 1735689600 si riferisce allo stesso istante a Tokyo, Berlino e São Paulo. Memorizzare quel numero invece di una stringa locale formattata significa non doversi mai chiedere a quale orologio appartenesse un valore. L'ordinamento è altrettanto banale, perché l'ordine cronologico è semplicemente l'ordine numerico, quindi un indice di database su una colonna timestamp ordina gli eventi correttamente senza alcuna analisi. L'aritmetica è ugualmente semplice: il divario tra due eventi è una sola sottrazione, e aggiungere un giorno equivale ad aggiungere 86400. Queste proprietà sono esattamente il motivo per cui log, token, cache e code di messaggi ricorrono all'epoch time.

Conversione in entrambe le direzioni

Passare da un timestamp a una data leggibile significa prendere il conteggio dei secondi e proiettarlo su un calendario, poi formattarlo nel fuso orario che ti interessa. Nel verso opposto, prendi anno, mese, giorno e ora, decidi in quale fuso orario sono espressi, e li comprimi in secondi dall'epoch. Il nostro strumento esegue entrambe le direzioni istantaneamente e interamente nel tuo browser, quindi niente di ciò che incolli lascia il tuo dispositivo. Incolla un numero per decodificarlo, o scegli una data per codificarla, e leggi il risultato sia in UTC che nell'ora locale nello stesso momento.

UTC contro ora locale, la trappola classica

Il timestamp stesso non ha un fuso orario; è sempre ancorato all'UTC. La confusione appare solo quando lo visualizzi. Se converti 1700000000 e il tuo schermo mostra un'ora serale mentre un collega in un altro paese vede un'ora pomeridiana, non c'è nulla di rotto — entrambi state guardando lo stesso istante renderizzato in orologi locali diversi. I bug si insinuano quando il codice legge una data locale come se fosse UTC, o marca un orario di parete senza registrare l'offset. L'abitudine sicura è memorizzare e trasmettere in UTC, e applicare un offset locale solo all'ultimo momento, quando mostri il valore a un essere umano. In caso di dubbio, confronta con la riga UTC nel convertitore piuttosto che con la tua ora locale.

Il problema dell'anno 2038

Molti sistemi più vecchi memorizzavano il tempo Unix in un intero con segno a 32 bit. Quel campo esaurisce lo spazio un secondo dopo le 03:14:07 UTC del 19 gennaio 2038, quando il contatore va in overflow e torna a un numero negativo, potenzialmente riportando le date al 1901. È la stessa famiglia di problemi del Y2K. La buona notizia è che i sistemi operativi e i linguaggi moderni sono ampiamente passati a timestamp a 64 bit, che non andranno in overflow per circa 292 miliardi di anni, quindi per il codice nuovo è per lo più una curiosità storica da conoscere piuttosto che un'emergenza.

Per altri aiuti basati su browser consulta i nostri strumenti per sviluppatori, e se hai bisogno di lavorare sui numeri stessi, le calcolatrici sono a un clic di distanza.

Domande frequenti