Un timestamp Unix è un numero solo: quanti secondi sono passati da mezzanotte UTC del 1° gennaio 1970. Il progetto è tutto qui, e la sua economia è il motivo per cui lo trovi ovunque: nei log, nei database, nei JWT, nelle API. Ed è anche il motivo per cui serve uno strumento, perché un numero come 1752537600 a un umano non dice assolutamente niente.
Secondi o millisecondi: il fattore 1000
Il tempo Unix conta secondi. JavaScript conta millisecondi: Date.now() restituisce un numero mille volte più grande, e lo stesso vale per ogni costruttore Date di JavaScript. Questo disallineamento è responsabile di più timestamp sbagliati di tutto il resto messo insieme.
Il sintomo è inconfondibile una volta che lo conosci. Passa un valore in secondi a qualcosa che si aspetta millisecondi e atterri nel gennaio 1970: tutto l'arco del tempo Unix fin qui diventa tre settimane. Passa millisecondi dove servono secondi e ottieni una data a cinquantamila anni da adesso. Nessuno dei due dà errore. Entrambi si formattano allegramente come una data, ed è questo che fa sopravvivere il bug alla revisione del codice.
Un controllo rapido: un timestamp attuale in secondi ha dieci cifre, in millisecondi ne ha tredici. Se stai fissando un numero e hai dubbi, conta le cifre prima di dividere.
Un timestamp non ha fuso orario
Vale la pena interiorizzarlo, perché dissolve gran parte della confusione sui fusi. Un timestamp Unix è un istante: lo stesso momento per chiunque sia vivo. Non è in UTC più di quanto sia nell'ora di Tokyo; semplicemente è. I fusi entrano in gioco solo quando quell'istante lo rendi come data leggibile, e quella è una decisione di visualizzazione, non una proprietà del dato.
Quindi "converti questo timestamp in UTC" non è affatto una conversione: è una scelta di formattazione. Il selettore di fuso qui cambia come lo stesso istante viene scritto, non cosa significa. È anche il motivo per cui conservare timestamp invece di stringhe di data locale risparmia tanto dolore: un istante è inequivocabile, "2025-10-26 02:30" no.
Il problema dell'anno 2038 è reale e morde già
Per decenni i sistemi Unix hanno conservato il tempo in un intero a 32 bit con segno. Quello finisce a 2147483647 secondi, cioè le 03:14:07 UTC del 19 gennaio 2038. Un secondo dopo il valore va in overflow, diventa negativo, e la data diventa 13 dicembre 1901.
Sembra un problema lontano e non lo è. Qualsiasi sistema che calcoli una data a più di qualche anno di distanza supera già la soglia: un mutuo trentennale, la scadenza di un certificato, una proiezione previdenziale. Bug di questo tipo si trovavano in produzione ben prima del 2020. Le piattaforme moderne sono in gran parte passate al tempo a 64 bit — che sposta il limite oltre la vita attesa del Sole — ma dispositivi embedded, vecchi formati di file e certe colonne di database no. Se oggi stai salvando un timestamp in una colonna a 32 bit, quello è un bug con una data di scadenza.
Il tempo Unix ignora deliberatamente i secondi intercalari
Ecco un fatto che sorprende anche sviluppatori esperti: un timestamp Unix non è un vero conteggio dei secondi trascorsi. Dal 1972 il mondo ha inserito 27 secondi intercalari per tenere gli orologi allineati alla rotazione terrestre, e il tempo Unix li salta tutti. Definisce ogni giorno come esattamente 86400 secondi, che quel giorno abbia davvero avuto 86400 secondi oppure no.
Lo scambio è voluto. Rende l'aritmetica banale — qualsiasi data si converte in timestamp con una semplice divisione — al prezzo di un conteggio leggermente sbagliato in senso assoluto. Significa anche che il vero secondo intercalare 23:59:60 non è proprio esprimibile: JavaScript lo rifiuta seccamente, e Date.parse("2016-12-31T23:59:60Z") restituisce NaN anche se quel secondo è realmente esistito. Se ti serve il tempo trascorso reale attraverso i secondi intercalari, il tempo Unix è lo strumento sbagliato; per il restante 99,99% del software questo compromesso è esattamente quello giusto.
Orari locali ambigui e impossibili
I timestamp sono puliti; gli orari locali no. Due volte l'anno l'ora legale fa comportare male l'orologio da parete. Quando a Roma le lancette tornano indietro l'ultima domenica di ottobre, le 02:30 accadono due volte: un orario locale "2025-10-26 02:30" corrisponde a due istanti diversi e niente nella stringa ti dice quale. Quando a marzo si va avanti, le 02:30 non esistono affatto.
È per questo che convertire una data locale in timestamp perde davvero informazione, in un modo in cui il contrario non fa mai. Se stai salvando appuntamenti, voci di log, qualsiasi cosa in cui l'istante esatto conta, salva il timestamp e rendi l'orario locale in uscita — non il contrario.
Domande frequenti
I miei dati vengono inviati a un server?
No. Questo strumento è marcato "client": la conversione è aritmetica e formattazione fatte nella scheda del tuo browser, con il suo database dei fusi orari. Non viene trasmesso niente.
Il mio timestamp mostra il 1970. Cosa è andato storto?
Qualcosa ha letto secondi come millisecondi. Moltiplica per 1000 e la data avrà senso. Di solito significa che un valore corretto nel database è stato passato dritto a un costruttore Date di JavaScript senza conversione: Date si aspetta millisecondi e non ti avvisa.
Un timestamp può essere negativo?
Sì, significa solo prima del 1970. Un timestamp di -1 è il 31 dicembre 1969 alle 23:59:59 UTC. La maggior parte del software lo gestisce correttamente, ma non tutto: i campi data di nascita per chi è nato prima del 1970 sono storicamente una miniera di bug nei sistemi i cui autori davano per scontato che i timestamp fossero sempre positivi.
Perché lo stesso timestamp mostra un'ora diversa sullo schermo del mio collega?
Perché siete in fusi diversi, ed è il comportamento corretto, non un bug. L'istante è identico; cambia solo come viene reso. Se hai bisogno che tutti leggano la stessa ora da orologio — una finestra di manutenzione programmata, per dire — dichiara il fuso esplicitamente accanto, oppure usa UTC e dillo.
Meglio salvare le date come timestamp o come stringhe?
Salva l'istante, come intero o come una vera colonna timestamp-con-fuso: il tuo database ne ha quasi certamente una, e gestirà intervalli e aritmetica che un intero nudo non può. Quello da evitare è una stringa di data locale senza fuso: è ambigua due volte l'anno ai cambi di ora legale, e non c'è modo di recuperare dopo l'informazione mancante.