Convertitore di timestamp Unix

Che cos’è un timestamp Unix

Un timestamp Unix — chiamato anche tempo epoch o tempo POSIX — è un singolo numero che conta quanti secondi sono passati dalle 00:00:00 UTC del 1º gennaio 1970, un istante noto come epoch di Unix. Trattandosi di un solo intero, senza fuso orario, senza calendario e senza formattazione, è il formato a cui i computer ricorrono ogni volta che un istante va memorizzato, ordinato, confrontato o spedito in rete. È ciò che sta dietro la colonna «created_at» del tuo database, dietro i claim «iat» ed «exp» di un JWT, dietro l’mtime di un file e dietro i timestamp di praticamente ogni file di log che ti capiterà di leggere.

Il rovescio della medaglia è che un numero nudo non dice nulla a una persona. 1716197600 è un istante perfettamente valido, ma a colpo d’occhio non sai se sia martedì scorso o tre anni fa. Questa traduzione, in entrambe le direzioni, è ciò che fa questo strumento.

Secondi o millisecondi: l’ambiguità che morde

La convenzione originale di Unix conta secondi interi, ed è quello che ottieni da date +%s in una shell, da time() in PHP e da time.time() in Python una volta troncato. JavaScript, Java e molti altri contano invece millisecondi: Date.now() restituisce un numero mille volte più grande. Entrambi si chiamano «timestamp», e confonderli è uno dei bug sulle date più comuni che esistano.

Il guasto è silenzioso, non rumoroso. Leggi un valore in millisecondi come secondi e la data atterra decine di migliaia di anni nel futuro; leggi un valore in secondi come millisecondi e tutto crolla al gennaio 1970. Nessuno dei due solleva un errore: semplicemente ottieni una data sbagliata che sembra vera.

Questo strumento tira a indovinare in base all’ordine di grandezza del numero e poi ti dice che cosa ha indovinato, proprio accanto al risultato. I secondi epoch di oggi hanno dieci cifre e i millisecondi tredici, quindi la deduzione è quasi sempre corretta — ma «quasi» non basta per un valore che stai per incollare in una segnalazione di bug, ed è per questo che l’interpretazione è sempre visibile e sempre a un clic dall’essere cambiata.

Fusi orari, UTC e perché «locale» è scivoloso

Un timestamp Unix non ha fuso orario. Identifica un istante: 1716197600 è 2024-05-20T09:33:20Z, e quello stesso istante è contemporaneamente le 10:33 a Londra, le 12:33 a Gerusalemme e le 18:33 a Tokyo, perché quel giorno Londra e Gerusalemme sono sull’ora legale e il Giappone non ne ha affatto. Il fuso orario non fa parte del valore: è la lente attraverso cui lo guardi.

Per questo lo strumento mostra più lenti insieme. UTC è il riferimento neutro su cui concordano tutti i server e tutti i log. La tua ora locale è quella che segnala il tuo dispositivo, mostrata con il nome del fuso (per esempio Europe/Berlin) così sai sempre quale lente l’ha prodotta: il rilevamento avviene nel tuo browser, quindi chi visita da Berlino vede l’ora di Berlino e chi visita da Tokyo quella di Tokyo. La terza riga è un fuso qualsiasi scelto dal database IANA completo, ed è la riga che ti serve quando leggi il log di un server che sta altrove.

• UTC: il riferimento su cui concordano tutti i sistemi, e la cosa giusta da memorizzare e registrare.
• Locale: lo stesso istante come lo vede il tuo dispositivo, etichettato con il fuso rilevato.
• Un fuso a tua scelta: per leggere log e tracce da macchine che stanno altrove.
• ISO 8601: il formato testuale di interscambio, ad es. 2024-05-20T09:33:20.000Z.
• Relativo: «3 ore fa», per farsi un’idea rapida di quanto sia recente qualcosa.

Gli scarti sono mostrati accanto a ogni orario (+03:00, -04:00) perché non sono fissi: la maggior parte dei fusi si sposta di un’ora con l’ora legale, quindi lo stesso fuso può produrre scarti diversi in periodi diversi dell’anno. Una data vicina a un cambio è esattamente il punto in cui i calcoli a mano sbagliano.

Lavorare con il tempo epoch nella pratica

Ogni linguaggio e ogni shell ha il proprio modo di produrre e leggere valori epoch. Questi vale la pena ricordarli:

date +%s                         # shell: ora corrente in secondi
date -d @1716197600              # shell (GNU): da secondi a data
Date.now()                       # JavaScript: ora corrente in MILLIsecondi
new Date(1716197600 * 1000)      # JavaScript: da secondi a Date
time.time()                      # Python: secondi, come decimale
datetime.fromtimestamp(1716197600, tz=timezone.utc)
SELECT EXTRACT(EPOCH FROM now()) -- PostgreSQL: secondi

Una regola pratica che evita gran parte dei dolori con le date: memorizza e trasmetti gli istanti in UTC — come intero epoch o come stringa ISO 8601 — e converti in un fuso locale solo all’ultimo momento, quando lo mostri davvero a qualcuno. Formattare troppo presto è il modo in cui un bug di fuso orario finisce cotto dentro i tuoi dati invece di restare nel livello di presentazione.

Un’altra cosa da sapere: un contatore di secondi a 32 bit con segno esaurisce il 19 gennaio 2038, il «problema dell’anno 2038». I sistemi moderni usano valori a 64 bit e non corrono rischi, ma i vecchi dispositivi embedded e le colonne di database ereditate sono proprio i posti in cui potresti ancora incontrarlo.

Che cos’è un epoch e perché non tutti i timestamp partono dal 1970

Un epoch, in questo senso, non è che uno zero scelto: l’istante da cui un contatore è definito per iniziare a contare. L’epoch di Unix sono le 00:00:00 UTC del 1º gennaio 1970, ed è stato scelto perché era una data tonda e comoda, non perché derivi da qualcosa: niente nel formato stesso richiede proprio quel giorno. Il primo Unix contava sessantesimi di secondo da uno zero molto più vicino, e il manuale della terza edizione disse senza giri di parole perché non poteva reggere: trentadue bit di sessantesimi garantiscono una crisi ogni 2,26 anni, cioè circa ogni 828 giorni. I secondi interi negli stessi trentadue bit arrivano a centotrentasei anni, o a sessantotto se il contatore ha segno, ed è la data del 2038 qui sopra.

Questa storia è il motivo per controllare un numero lungo prima di fidarsene. Altri sistemi contano da altri zeri e con altre risoluzioni, e leggerne uno come secondi Unix non ti sposta di qualche ora: ti sposta di secoli. Questi sono quelli che più probabilmente ti capiteranno:

• Windows FILETIME: tick da cento nanosecondi dal 1º gennaio 1601 UTC. Dividi per dieci milioni e sottrai 11644473600 per ottenere secondi Unix; l’istante 1716197600 usato in tutta questa guida è 133606712000000000 in quello schema.
• .NET DateTime.Ticks: lo stesso tick da cento nanosecondi, ma contato dall’inizio dell’anno 1. L’epoch di Unix sta a 621355968000000000 tick, ed è il numero da sottrarre prima di dividere.
• La data di riferimento di Apple: secondi dal 1º gennaio 2001 UTC, usata da Cocoa e Core Data. Aggiungi 978307200 per ottenere secondi Unix: 1716197600 lì è 737890400.
• I numeri seriali di Excel: giorni anziché secondi, contati dal 30 dicembre 1899, perché Excel tratta il 1900 come anno bisestile e non lo era.
• Il tempo GPS: secondi dal 6 gennaio 1980, contati senza saltare mai un secondo intercalare, così il tempo GPS e UTC non concordano più.

Quest’ultimo indica qualcosa di vero anche per il valore Unix stesso: non è la lettura di un cronometro. POSIX lo definisce come un valore che approssima i secondi trascorsi dall’epoch e impone che ogni singolo giorno sia contato per esattamente 86400 secondi, quindi i secondi intercalari inseriti in UTC non vengono contati affatto. La differenza fra due timestamp Unix è perciò il numero di secondi di calendario che li separano e non il numero di secondi realmente trascorsi, e il valore si capisce meglio come la codifica di una lettura di calendario in UTC. È anche il motivo per cui nessun timestamp nomina mai un secondo intercalare: la codifica non ha una casella per uno.

Da una data a un valore epoch: shell, JavaScript e Python

Il blocco qui sopra trasforma un valore epoch in qualcosa di leggibile. La direzione opposta — una data che hai già, come testo o come insieme di numeri, trasformata in valore epoch — è dove vivono i bug di fuso orario, perché ognuno di questi assume in silenzio un fuso quando il testo non ne nomina uno. Ecco lo stesso lavoro in tre modi, sull’istante 2024-05-20T09:33:20Z di questa guida. Le righe di shell sono il date di GNU; quello di BSD e macOS accetta altre opzioni.

date -u -d '2024-05-20 09:33:20' +%s     # 1716197600 — -u legge il testo come UTC
date -d '2024-05-20 09:33:20 UTC' +%s    # lo stesso, con il fuso nominato nel testo
date -d '2024-05-20 09:33:20' +%s        # né l’uno né l’altro: il fuso della tua macchina

Date.parse('2024-05-20T09:33:20Z') / 1000    // 1716197600 — è la Z a renderlo UTC
new Date('2024-05-20T09:33:20Z').getTime()   // lo stesso istante in millisecondi
Date.parse('2024-05-20 09:33:20')            // senza Z: il fuso della tua macchina

from datetime import datetime, timezone
int(datetime(2024, 5, 20, 9, 33, 20, tzinfo=timezone.utc).timestamp())   # 1716197600 — datetime consapevole
int(datetime.fromisoformat('2024-05-20T09:33:20+00:00').timestamp())     # lo stesso, letto da una stringa
int(datetime(2024, 5, 20, 9, 33, 20).timestamp())                        # ingenuo: il fuso della tua macchina

Lo schema è identico in tutti e tre: nomina il fuso, oppure erediti quello su cui è impostata la macchina. Un numero giusto sul tuo portatile e sbagliato di ore su quello di un collega è quasi sempre questo, ed è il motivo per cui lo strumento qui sopra mostra UTC e la tua lettura locale affiancate invece di sceglierne una per te. Se il numero ce l’hai già e vuoi controllarlo a occhio, incollalo nel campo in cima a questa pagina.