Convertitore di Timestamp Unix Gratuito

Cos'è un Timestamp Unix?

Un timestamp Unix (chiamato anche tempo epoch o tempo POSIX) è il numero di secondi trascorsi dal 1° gennaio 1970, 00:00:00 UTC. È un modo semplice e indipendente dal fuso orario per rappresentare un istante nel tempo ed è ampiamente utilizzato nella programmazione, nei database, nelle API e nei log dei server.

Ad esempio, il timestamp 1700000000 rappresenta il 14 novembre 2023 alle 22:13:20 UTC. JavaScript utilizza timestamp in millisecondi (moltiplicare per 1000), mentre la maggior parte degli altri linguaggi e API usa i secondi.

Domande frequenti

Quali formati di data posso inserire?

Puoi inserire date nella maggior parte dei formati standard: ISO 8601 (2025-12-31T23:59:59Z), stringhe di data comuni (Dec 31, 2025 11:59 PM) o formati semplici come 2025-12-31 23:59:59. Il convertitore utilizza il parser di date integrato del tuo browser.

Rileva automaticamente secondi vs millisecondi?

Sì. Se il timestamp è maggiore di 1 trilione, il convertitore lo tratta come millisecondi. Altrimenti, lo tratta come secondi. Entrambi i formati sono mostrati nella tabella dei risultati.

Cos'è il problema dell'anno 2038?

I sistemi che memorizzano i timestamp Unix come interi con segno a 32 bit andranno in overflow il 19 gennaio 2038 alle 03:14:07 UTC. I sistemi moderni utilizzano interi a 64 bit, in grado di rappresentare date a miliardi di anni nel futuro. Questo strumento utilizza il tipo Number di JavaScript, che gestisce timestamp ben oltre il 2038.

Perché il 1° gennaio 1970?

Un timestamp Unix è un conteggio intero dei secondi trascorsi dall'epoca Unix, 00:00:00 UTC di giovedì 1° gennaio 1970. È un singolo scalare che identifica univocamente un istante nel tempo, indipendente dal calendario e dal fuso orario, lo stesso numero indica lo stesso istante sia che tu sia a Tokyo o a Toronto.

La scelta del 1970 è stata in qualche modo arbitraria, ma non casuale. La prima edizione del UNIX Programmer's Manual (novembre 1971) definiva il tempo di sistema come il numero di tick di clock a 60 Hz dal 1° gennaio 1971. Con un intero senza segno a 32 bit che conta a 60 Hz, il sistema sarebbe durato solo circa 2,26 anni prima dell'overflow, un problema che divenne presto evidente. Quando si preparava la seconda edizione nel 1972, il team di Ken Thompson e Dennis Ritchie passò a contare i secondi dal 1° gennaio 1970: gli interi con segno a 32 bit che contano i secondi sarebbero durati circa 68 anni, comodamente oltre la vita lavorativa degli ingegneri che scrivevano il codice, e il più recente Capodanno prima dell'inizio del progetto rendeva l'aritmetica facile. Non ci fu alcun voto di comitato né processo di standardizzazione in stile IANA. La scelta si è cristallizzata perché Unix fu spedito con essa, e una volta che cento milioni di macchine contavano da quel momento, nessuna sostituzione era praticabile.

POSIX (1988) ha codificato l'epoca 1970 come "Seconds Since the Epoch" di IEEE Std 1003.1. Oggi la stessa epoca sostiene time_t di C/C++, time.time() di Python, Time.now.to_i di Ruby, JavaScript e Java (in millisecondi, vedi sotto), i timestamp dei file system Linux/macOS, le intestazioni dei blocchi di Bitcoin ed Ethereum, e i claim iat/exp/nbf dei JWT. Alcuni sistemi usano epoche offset (FILETIME di Windows conta tick di 100 nanosecondi dal 1° gennaio 1601, DateTime di .NET conta tick dal 1° gennaio 0001), ma il tempo Unix è la lingua franca per tutto ciò che attraversa un confine di sistema operativo o di linguaggio.

Secondi vs millisecondi, il bug più comune

POSIX definisce il timestamp come secondi dall'epoca. Ogni libreria C, ogni interprete Python, ogni runtime Ruby/Go/Rust/Elixir restituisce secondi. JavaScript è la famosa eccezione, Date.now() e new Date().getTime() restituiscono millisecondi. System.currentTimeMillis() di Java segue la stessa convenzione, e diversi sistemi di database più recenti (il tipo Date di MongoDB BSON, per esempio) memorizzano anch'essi millisecondi.

Il risultato è un bug perenne tra linguaggi: un backend Go scrive 1700000000 (secondi) in un campo JSON; un client Node.js lo passa a new Date(1700000000), ma JavaScript si aspetta millisecondi, quindi la data risultante è 1970-01-20 invece di fine 2023. La correzione è new Date(1700000000 * 1000). Al contrario, inviare un timestamp in millisecondi JS a datetime.fromtimestamp() di Python produce l'anno ~55895. Stack Overflow ha decine di varianti delle domande "JavaScript Date che mostra 1970", e il mismatch è la causa principale nella stragrande maggioranza dei casi.

Questo convertitore implementa un'euristica: se l'input è maggiore di 1.000.000.000.000, lo tratta come millisecondi; altrimenti lo tratta come secondi. Funziona perché 1e12 secondi sarebbero l'anno 33658 d.C. (ben oltre qualsiasi input reale su scala di secondi), mentre 1e12 millisecondi è il 9 settembre 2001 UTC (nell'intervallo moderno). Timestamp in microsecondi e nanosecondi usati in alcuni sistemi scientifici e API del kernel Linux spingerebbero la soglia più in alto, per quelli dovrai specificare la precisione esplicitamente.

Il problema dell'anno 2038 ("Y2K38")

Un intero con segno a 32 bit può memorizzare valori da −2.147.483.648 a +2.147.483.647. Interpretato come secondi dal 1° gennaio 1970 UTC, l'istante massimo rappresentabile è 03:14:07 UTC di martedì 19 gennaio 2038. Un secondo dopo, il contatore va in overflow e si avvolge al valore più negativo, che si decodifica come 20:45:52 UTC di venerdì 13 dicembre 1901. Qualsiasi time_t di larghezza 32 bit, qualsiasi colonna di database che memorizza un intero con segno a 4 byte per il tempo, e qualsiasi sistema embedded il cui firmware è stato scritto prima del 2010 circa è a rischio.

La superficie esposta è scomoda: PLC industriali e controllori SCADA con cicli di vita di installazione di 15-30 anni installati oggi; vecchie colonne TIMESTAMP di MySQL che documentano la saturazione al confine del 2038; filesystem ext3; formati di protocollo binario (campi RRSIG DNSSEC, NTPv3, diversi fieldbus industriali) che impacchettano un timestamp a 4 byte; smart TV e infotainment automobilistico che eseguono silenziosamente kernel Linux a 32 bit più vecchi. La correzione mainstream consiste nell'ampliare time_t a 64 bit, il che estende il massimo a circa +292 miliardi di anni, oltre la morte termica del Sole. Linux 5.6 (marzo 2020) ha aggiunto le syscall di tempo a 64 bit a tutte le architetture a 32 bit tramite il patchset y2038 di Arnd Bergmann; glibc 2.34 (agosto 2021) ha reso time_t a 64 bit opt-in tramite _TIME_BITS=64; Debian 13 "Trixie" (2025) è la prima release con l'archivio completo ricompilato. Apple ha deprecato i binari a 32 bit in macOS 10.15 (2019) e iOS 11 (2017), quindi la flotta dei consumatori è di fatto immune.

La superficie di rischio rimanente è in modo schiacciante embedded e dati legacy su disco: un kernel a 64 bit che legge una colonna timestamp a 32 bit da un database legacy è altrettanto rotto del database stesso. La migrazione è un problema di formato dati per ogni applicazione, non solo un problema del kernel.

JavaScript Date, l'API più maledetta del campo

L'oggetto Date di JavaScript è stato copiato di sana pianta da Java 1.0 nel maggio 1995 durante lo sprint di 10 giorni in cui Brendan Eich scrisse l'originale LiveScript. Java stesso ha deprecato la maggior parte dei metodi di java.util.Date in JDK 1.1 (1997), ma JavaScript li ha ereditati e non poteva rompere la compatibilità con il web, quindi rimangono. Il risultato è un'API in cui:

• I mesi sono indicizzati da 0 (new Date(2024, 0, 15) = 15 gennaio) ma i giorni sono indicizzati da 1.
• getYear() restituisce "anno meno 1900", getYear() per il 2024 è 124. getFullYear() è stato aggiunto più tardi per restituire 2024 direttamente.
• Date.parse('2024-03-15') viene analizzato come mezzanotte UTC; Date.parse('2024/03/15') è mezzanotte locale; Date.parse('March 15, 2024') è definito dall'implementazione.
• Prima di ECMAScript 5 (dicembre 2009) il parsing era quasi interamente definito dall'implementazione, la stessa stringa di input poteva produrre valori Date diversi in IE, Firefox, Chrome e Safari.

L'API Temporal (TC39 Stage 3 da marzo 2021) è il sostituto moderno, che fornisce Temporal.Instant, Temporal.PlainDate, Temporal.PlainTime, Temporal.ZonedDateTime e un vero tipo Temporal.Duration. Il supporto del browser sta arrivando (Firefox Nightly, Safari 18 parziale, Chrome dietro un flag al 2024); i polyfill funzionano ma aggiungono ~25 KB. Moment.js è stato messo in modalità manutenzione dai suoi manutentori a settembre 2020, per nuovi progetti nel 2026 la raccomandazione è Temporal-first se il supporto del browser lo consente, Luxon o date-fns altrimenti, e Moment.js mai.

Quando ti serve

• Debug delle risposte API. La maggior parte delle API JSON restituisce timestamp come interi Unix o stringhe ISO 8601, e molte li mescolano. Incollare un numero in un convertitore decine di volte al giorno è il caso d'uso a maggior volume.
• Analisi dei file di log. syslog, journald, AWS CloudWatch e la maggior parte dei log delle applicazioni hanno timestamp in secondi Unix. Gli ingegneri copiano un timestamp da una riga di log e devono conoscere l'equivalente orario.
• Ispezione di colonne data nei database. Una query psql o mysql occasionale restituisce 1700000000; il database ha funzioni come FROM_UNIXTIME() ma uno strumento del browser è più veloce per il lavoro ad-hoc.
• Ispezione JWT. Decodificare un token OAuth mostra "exp": 1738367200. Questo token è scaduto? Quando scade? Un convertitore di timestamp è la risposta più veloce.
• Timestamp blockchain. Il nTime del blocco di Bitcoin è in secondi Unix (overflow nel 2106, 4 byte senza segno). Anche i timestamp dei blocchi Ethereum sono in secondi Unix.
• Metadati del file system del SO. ls -l --time-style=+%s stampa mtime Unix; stat -c '%Y' filename restituisce mtime come intero. La riconciliazione forense dei timestamp spesso comporta la decodifica manuale.
• Certificati notBefore / notAfter e header HTTP If-Modified-Since, tutti timestamp che occasionalmente devono essere decodificati.

Una nota sui secondi intercalari

Dal 1972, 27 secondi intercalari sono stati inseriti in UTC per mantenere il tempo dell'orologio a muro allineato con la rotazione della Terra che rallenta. Il più recente è stato il 31 dicembre 2016 23:59:60 UTC. Il tempo Unix non codifica i secondi intercalari, POSIX dice esplicitamente che un timestamp Unix finge che ogni giorno abbia esattamente 86.400 secondi. I sistemi Linux più vecchi "ripetono" l'ultimo secondo; Google e AWS usano un "leap smear" che distribuisce il secondo extra su una finestra di 24 ore. In ogni caso, il tempo Unix non legge mai 23:59:60 nell'archiviazione, e sottrarre due timestamp che attraversano un secondo intercalare produce una risposta inferiore di un secondo al tempo trascorso reale in secondi SI. Per il codice applicativo questo è invisibile. Per il software astronomico o di trading finanziario può importare. A novembre 2022, la 27ª Conferenza Generale dei Pesi e delle Misure ha votato per fermare l'inserimento di secondi intercalari entro il 2035, sostituendoli con un aggiustamento periodico molto più grande.

Riferimento rapido

Timestamp	UTC datetime	Note
0	1970-01-01 00:00:00	The epoch
1,000,000,000	2001-09-09 01:46:40	First "billion-second" milestone
1,234,567,890	2009-02-13 23:31:30	"Cool number" celebrated by some devs
1,700,000,000	2023-11-14 22:13:20
2,000,000,000	2033-05-18 03:33:20	"Two billionth second"
2,147,483,647	2038-01-19 03:14:07	Last second representable in signed 32-bit
4,294,967,295	2106-02-07 06:28:15	Last representable in unsigned 32-bit (Bitcoin's nTime limit)
9,999,999,999	2286-11-20 17:46:39	Last 10-digit timestamp

Altre domande

Perché lo stesso timestamp mostra un orario diverso sulla macchina del mio amico?

Perché il numero sottostante è UTC, ma la visualizzazione lo converte nell'ora locale. 1700000000 è 22:13:20 UTC, ma 17:13:20 a New York e 06:13:20 del giorno successivo a Sydney. Il numero è lo stesso; solo la rappresentazione differisce. Per escludere confusioni di fuso orario, chiedi a entrambe le macchine di visualizzare in UTC.

Qual è la differenza tra Y2K e Y2K38?

Y2K (anno 2000) era un problema di logica nel codice applicativo: molti sistemi memorizzavano gli anni come due cifre ASCII, quindi "00" diventava ambiguo tra 1900 e 2000. Ogni applicazione doveva essere ispezionata e corretta individualmente; la spesa totale di rimedio in tutto il mondo è stata stimata in 300-600 miliardi di dollari. Y2K38 è principalmente un problema di tipo di dati nelle librerie di basso livello, ricompilare la libreria C e il kernel contro time_t a 64 bit risolve un'enorme frazione della superficie per ogni applicazione che vi si collega. I casi difficili rimanenti sono i dati persistiti su disco (database, metadati di file, protocolli binari) che richiedono strumenti di migrazione dati. La saggezza convenzionale è che il 2038 sarà un evento più piccolo e meno notiziabile del 2000, più guasti localizzati di dispositivi embedded, meno interruzioni di cronaca.

Perché new Date('2024-03-15') a volte mostra il 14 marzo?

Perché quella stringa viene analizzata come mezzanotte UTC secondo lo standard ES5, e poi visualizzata nel tuo fuso orario locale. In una zona UTC-8 come il Pacifico USA, la mezzanotte UTC del 15 marzo è le 16:00 del 14 marzo ora locale, quindi .getDate() restituisce 14. La correzione nel codice moderno è o new Date('2024-03-15T12:00:00') (che JavaScript analizza come mezzogiorno locale quando ometti la Z) o, meglio, l'API Temporal.PlainDate.from() una volta che sarà spedita.

Qualcosa viene inviato a un server?

No. La conversione è aritmetica JavaScript che gira localmente nel tuo browser. Nulla dei timestamp che inserisci lascia la pagina, utile quando i valori sono ID cliente, righe di log interne o dati di debug di sessione che preferiresti non caricare da nessuna parte. La pagina funziona offline una volta caricata.

Strumenti correlati