Convertitore timestamp Unix

Che cos’è un timestamp Unix

Un timestamp Unix è un numero solo: quanti secondi sono passati dall’inizio del 1970 in UTC. Tutto qui. Non porta con sé fuso orario, ora legale, calendario né formattazione, ed è proprio per questo che è ciò che i sistemi conservano e si scambiano. Due server ai lati opposti del mondo sono d’accordo sul numero anche quando non sono d’accordo su come chiamarlo.

Il rovescio è che un timestamp da solo non può rispondere a «che ore erano». Può dirti l’istante, ma trasformare un istante in una lettura da orologio richiede un fuso orario, e quell’informazione il numero non la contiene. È per questo che un convertitore deve mostrare la lettura UTC e quella locale come due risposte separate invece che come una.

Come si usa

• Da timestamp a data incolla il numero. L’unità si riconosce dalla dimensione, e il risultato mostra la forma ISO 8601, la tua ora locale, il giorno della settimana e quanto tempo fa è stato.
• Da data a timestamp scrivi una data. 2026-03-02, 2026-03-02T14:30:00Z e 2026-03-02T14:30:00+01:00 funzionano tutte e danno risposte diverse, correttamente.
• Leggi come imponi secondi o millisecondi quando la scelta automatica non è quella che vuoi: succede con timestamp precedenti al 1973 o molto lontani nel futuro.
• Usa l’ora attuale compila adesso, ed è il modo più rapido per vedere che aspetto deve avere un timestamp di questi giorni.
• Guarda l’avviso sul fuso se la data che hai scritto non porta un fuso, la pagina lo dice. È la differenza tra una risposta corretta e una risposta giusta solo sul tuo computer.

La trappola dei fusi orari, nel dettaglio

Tre stringhe quasi identiche indicano tre istanti diversi. 2026-03-02 è mezzanotte UTC, perché la forma ISO 8601 con la sola data è definita così e JavaScript la segue. 2026-03-02T00:00:00 ha l’ora ma non il fuso, quindi è mezzanotte locale, che a Roma sono le 23:00 del giorno prima in UTC. E 2026-03-02T00:00:00Z è di nuovo UTC esplicito. Una di quelle tre è quella che intendevi; le altre due sono bug che aspettano qualcuno in un altro paese per eseguire il tuo codice.

L’ora legale peggiora le cose in un modo che nessun numero può sistemare. In quasi tutta Europa l’ultima domenica di marzo non ha nessun 02:30, le lancette saltano dalle 02:00 alle 03:00, e l’ultima domenica di ottobre ne ha due. Un timestamp regge senza problemi, perché non è mai uscito da UTC. Un’ora locale scritta come testo no: le 02:30 di quella domenica o non esistono o sono ambigue, e qualunque cosa ne faccia la tua libreria è un’ipotesi.

La regola pratica che segue: conserva l’istante, formatta ai bordi. Tieni timestamp o UTC nel database, converti nel fuso del lettore quando mostri, e non fare mai aritmetica su una stringa di ora locale. L’ora che aggiungi all’01:30 della domenica sbagliata non è l’ora che credi.

Quando il numero sembra sbagliato

• La data esce nel 1970 un valore in millisecondi è stato letto come secondi, dividendo per mille l’età del tuo timestamp. Imponi i millisecondi.
• La data è a decine di migliaia di anni da qui il contrario: secondi letti come millisecondi. Imponi i secondi.
• Sbagliata di esattamente una o due ore un fuso, quasi sempre. Un’ora è l’offset standard, due sono offset più ora legale; nessuno dei due è un arrotondamento.
• Sbagliata di esattamente un giorno una stringa con la sola data letta come mezzanotte UTC da un lato e mezzanotte locale dall’altro. Aggiungi un fuso esplicito e sparisce.
• Timestamp negativi perfettamente validi: sono date prima del 1970. Alcuni sistemi li rifiutano comunque, cosa che è un bug di quei sistemi e una cosa da testare.
• Un JWT che sembra scaduto e non lo è il claim exp è in secondi, e del codice che lo confronta con Date.now(), che è in millisecondi, crederà che ogni token sia scaduto nel 1970.

Le parole intorno

• Epoch il punto zero da cui un sistema di tempo conta. L’epoch Unix è 1970-01-01T00:00:00Z; altri sistemi hanno scelto altre date, ed è per questo che un timestamp di una piattaforma può essere decenni fuori in un’altra.
• UTC il tempo di riferimento verso cui tutto converte. Non è il fuso di nessuno e, in senso stretto, non è la stessa cosa di GMT, anche se i due concordano entro un secondo.
• ISO 8601 il formato testuale: 2026-03-02T14:30:00Z. Si ordina correttamente come stringa, ed è il motivo per cui è la scelta giusta per un log o per il nome di un file.
• Secondi intercalari secondi aggiunti per tenere gli orologi al passo con la Terra. Il tempo Unix li ignora per definizione, ed è il motivo per cui è un contatore pulito e non un conteggio vero dei secondi trascorsi.
• Il problema dell’anno 2038 un timestamp a 32 bit con segno va in overflow il 19 gennaio 2038. Tutto ciò che conserva il tempo Unix in un int32, vecchi sistemi embedded, certe colonne di database, si ferma o salta al 1901.