Convertitore di timestamp Unix Epoch gratuito

Cos'è il tempo Unix (epoch)?

Il tempo Unix (chiamato anche POSIX) è il modo standard di rappresentare il tempo in informatica. Conta il numero di secondi (o millisecondi) trascorsi dal 1° gennaio 1970 alle 00:00:00 UTC. Questo singolo numero facilita la memorizzazione, il confronto e il calcolo di differenze di tempo tra sistemi e fusi orari diversi.

La scelta del 1° gennaio 1970 e altre epoche

L'epoca 1970-01-01 risale ai primi giorni di Unix ai Bell Labs. Il tipo time_t di Unix era originariamente un intero a 32 bit con segno che contava i secondi da una baseline scelta; il team scelse il Capodanno più recente prima dell'inizio dello sviluppo, cioè il 1° gennaio 1970. La decisione fu pratica, non filosofica, Unix era in sviluppo nel 1969-1971 e un'epoca recente massimizzava l'intervallo utilizzabile dei timestamp all'interno del range dei 32 bit con segno. Altri sistemi hanno scelto altre epoche adatte ai loro casi d'uso. NTP (Network Time Protocol, RFC 5905) usa il 1° gennaio 1900 come epoca, importante perché NTP doveva coprire intervalli storici più lunghi. Windows FILETIME usa il 1° gennaio 1601 come epoca a tick di 100 nanosecondi (l'inizio del ciclo gregoriano di 400 anni che includeva il 1601). VAX/VMS ha usato il 17 novembre 1858 (l'epoca del Modified Julian Day, popolare in astronomia). Mac classico ha usato il 1° gennaio 1904. JavaScript Date usa l'epoca Unix ma conta in millisecondi anziché secondi (un float a 64 bit, che dà ±100 milioni di anni di intervallo utilizzabile). Il punto: l'epoca Unix è dominante nel 2026, ma la storia contiene molte altre scelte, ciascuna con la propria eredità di compatibilità all'indietro.

Il problema Y2K38, il tempo Unix sta per esaurirsi (un po')

Se time_t è un intero a 32 bit con segno (il design Unix originale), il timestamp massimo rappresentabile è 2.147.483.647, che corrisponde al 03:14:07 UTC di martedì 19 gennaio 2038. Un secondo dopo, il valore va in overflow al negativo, tornando indietro al 13 dicembre 1901. Questo è il problema Y2K38 (chiamato anche Epochalypse). Sui sistemi moderni a 64 bit, time_t è un intero a 64 bit con segno e la data di overflow è 4 dicembre 292.277.026.596, comodamente oltre la morte del sole. Ma i sistemi embedded a 32 bit sono ancora attivamente in uso in controllori industriali, satelliti con missioni di lunga durata, sistemi di back-end bancari, reti SCADA del settore oil & gas, infotainment automobilistico e sensori IoT con cicli di vita di progettazione pluridecennali. La mitigazione è in corso dai primi anni 2000, ogni grande OS, database e linguaggio ora usa di default tempo a 64 bit su hardware a 64 bit (Linux ha completato la transizione nel kernel 5.6, marzo 2020; Windows ha sempre usato 64 bit; macOS Catalina ha abbandonato il supporto a 32 bit nel 2019). I sistemi embedded sono la coda lunga. Y2K38 non sarà una crisi di un solo giorno come fu Y2K; sarà una serie di piccoli guasti in sistemi della coda lunga negli anni vicini al 2038, esattamente nel modo in cui Y2K si è manifestato perlopiù in sistemi oscuri che nessuno aveva aggiornato.

ISO 8601, l'altro formato standard del tempo

Mentre Unix time è il formato di trasmissione, ISO 8601 è il formato leggibile dall'uomo. Pubblicato originariamente come ISO 8601:1988, rivisto nel 2000, 2004 e più recentemente in ISO 8601-1:2019 e ISO 8601-2:2019, lo standard definisce rappresentazioni come 2026-05-03T14:30:00Z (con la Z che significa UTC) o 2026-05-03T14:30:00+01:00 (con l'offset esplicito). La "T" separa la data dall'ora; l'offset finale disambigua il fuso orario. Per i protocolli internet, RFC 3339 (Klyne e Newman, 2002) definisce un sottoinsieme rigoroso di ISO 8601 più facile da analizzare, è il formato che vedrai nelle risposte JSON delle API, nei timestamp dei log, nei campi exp/iat dei JWT e nei flussi OAuth. La relazione con Unix time: ISO 8601 è la forma leggibile dall'uomo di un istante; Unix time è la forma intera dello stesso istante. Un convertitore come questo si muove tra di essi in entrambe le direzioni. La forma ora locale (2026-05-03T14:30:00 senza offset) è ambigua e va evitata in qualsiasi sistema che attraversi fusi orari, è frequentemente la fonte di bug sottili in cui un'API JSON dichiara di restituire timestamp ma non dice in quale fuso orario sono.

Secondi contro millisecondi, la confusione comune

Unix time a livello di sistema operativo conta secondi, un intero di 10 cifre per qualsiasi istante tra circa il 2001 e il 2286 (i timestamp prima del 2001 avevano 9 cifre o meno). Il Date.now() di JavaScript, il System.currentTimeMillis() della JVM, il DateTimeOffset.ToUnixTimeMilliseconds() di .NET e la maggior parte delle web API contano millisecondi, un intero di 13 cifre per lo stesso intervallo. Le due forme differiscono esattamente di un fattore 1.000, e il bug più comune nei timestamp in qualsiasi codice che parla con più sistemi è passare un valore in millisecondi a una funzione che si aspetta secondi (dando una data 1.000 volte più nel futuro del previsto) o viceversa (dando una data una frazione di secondo dopo l'epoca). Questo convertitore rileva automaticamente in base al numero di cifre: 10 cifre o meno = secondi, 13 o più = millisecondi. Per valori intermedi (11-12 cifre, ambigui), il convertitore preferisce l'interpretazione che dà una data sensata. Microsecondi (16 cifre, usati da alcuni sistemi ad alta precisione e da molti tipi TIMESTAMP nei database) e nanosecondi (19 cifre, usati da clock_gettime di Linux, time.UnixNano() di Go, strumenti di osservabilità moderni come OpenTelemetry) si incontrano anche, ma sono meno comuni nei dati visibili all'utente.

Usi comuni della conversione di timestamp

• Debug di API · converti i timestamp delle risposte API per capire quando un dato è stato creato o modificato.
• Analisi di log · leggi e capisci i timestamp dei log di server e applicazioni.
• Debug di JWT. Le rivendicazioni exp (scadenza) e iat (issued-at) nei JSON Web Token sono interi Unix-time secondo la RFC 7519. Per controllare se un token è scaduto o per vedere quando è stato emesso, incolla il valore qui.
• Calcolo della differenza temporale. Sottrai due timestamp Unix per ottenere la durata tra di essi in secondi (o millisecondi). Niente matematica del fuso orario, niente regolazioni dell'ora legale, niente casi limite di aritmetica del calendario.
• Query di database con colonne epoch. Molti database più vecchi memorizzano i timestamp come interi Unix. Interrogare "tutti gli eventi tra X e Y" richiede di convertire le date di taglio leggibili dall'uomo in interi Unix per la clausola WHERE.
• Pianificazione e task cron. I sistemi che pianificano lavori per tempo assoluto (Kubernetes CronJobs, AWS EventBridge, Azure Logic Apps) spesso vogliono target in Unix time nella loro configurazione. Converti l'orario obiettivo amichevole all'utente in epoch.
• Decifrare timestamp "interessanti". Valori epoch famosi: 0 = 1° gennaio 1970 00:00:00 UTC (l'epoca stessa); 1234567890 = 13 febbraio 2009 23:31:30 UTC (brevemente celebrato come il "miliardo Unix"); 1500000000 = 14 luglio 2017 02:40:00 UTC; 2000000000 = 18 maggio 2033 03:33:20 UTC; 2147483647 = 19 gennaio 2038 03:14:07 UTC (il punto di overflow Y2K38).

Una nota sui leap second e sul tempo "reale"

Una sottile complicazione: Unix time come definito da POSIX non include i leap second. Il tempo coordinato universale (UTC) aggiunge occasionalmente un leap second per mantenere il tempo civile allineato con la rotazione effettiva della Terra, sono stati aggiunti 27 leap second dall'inizio del sistema nel 1972. Unix time finge che quei leap second non siano accaduti: quando un leap second viene inserito alla fine di un giorno, l'orologio o ripete l'ultimo secondo (comportamento tradizionale di Linux) o lo distribuisce su un periodo più lungo (l'approccio "leap smear" di Google, adottato da AWS e molti CDN). Per la maggior parte dell'uso applicativo, non importa, l'accuratezza temporale sub-secondo raramente è significativa al livello applicativo. Per il lavoro scientifico ad alta precisione, i timestamp dei sistemi di trading finanziario o i timestamp legali probatori, il comportamento dei leap second è una nota fonte di casi limite. L'IERS (International Earth Rotation and Reference Systems Service) annuncia i leap second con sei mesi di preavviso; il più recente è stato inserito alla fine del 31 dicembre 2016, e la comunità internazionale sta valutando di ritirare del tutto i leap second (la risoluzione per farlo entro il 2035 è stata adottata alla Conferenza Generale dei Pesi e delle Misure del 2022).

Privacy: conversione solo nel browser

I timestamp che incolli di solito non sono sensibili in sé (un intero Unix rivela solo un istante nel tempo), ma il contesto, una riga di log che contiene un identificativo utente reale insieme al timestamp, un JWT che contiene rivendicazioni su un utente reale, una risposta API con ID di entità interni, lo è frequentemente. Questo convertitore funziona interamente nel tuo browser tramite l'API Date integrata di JavaScript. Nessun upload, nessun log, verifica nel pannello Network di DevTools mentre digiti un timestamp (nessuna richiesta parte) o metti la pagina offline (modalità aereo) dopo il caricamento. La visualizzazione "now" che si aggiorna in tempo reale usa il tuo orologio locale, non una sorgente di tempo di rete.

Domande frequenti

Cos'è un timestamp Unix?

Un timestamp Unix (chiamato anche tempo Epoch o POSIX) è il numero di secondi (o millisecondi) dal 1° gennaio 1970 alle 00:00:00 UTC. È un modo standard di rappresentare il tempo in informatica.

Qual è la differenza tra secondi e millisecondi?

I timestamp Unix possono essere in secondi (10 cifre, per es. 1711824000) o in millisecondi (13 cifre, per es. 1711824000000). Questo strumento rileva automaticamente in base alla lunghezza dell'input.

Perché la mia ora convertita è sfasata di diverse ore?

Il convertitore mostra i formati ora locale, UTC e ISO 8601. Se il risultato non corrisponde all'ora prevista, verifica di leggere il formato che tiene conto del fuso orario (differenza UTC vs ora locale).

Cos'è il problema Y2K38?

Se Unix time è memorizzato in un intero a 32 bit con segno (il design Unix originale), va in overflow il 19 gennaio 2038 alle 03:14:07 UTC. I sistemi moderni a 64 bit non sono interessati, la data di overflow si sposta a circa l'anno 292 miliardi. Il rischio Y2K38 è concentrato nei sistemi embedded a 32 bit ancora in uso (controllori industriali, satelliti, infotainment automobilistico, back-end bancari, sensori IoT con cicli di vita pluridecennali). A differenza del Y2K, il problema Y2K38 non sarà una crisi di un solo giorno ma una serie di piccoli guasti in sistemi della coda lunga negli anni vicini al 2038.

Funziona offline?

Sì, una volta caricata la pagina, tutta la conversione avviene nel tuo browser tramite l'API Date integrata di JavaScript. Nessuna chiamata di rete durante l'uso. Il pulsante "Now" usa l'orologio locale del tuo dispositivo; il timestamp che si aggiorna in tempo reale in cima si aggiorna dall'orologio di sistema senza contattare alcun server di tempo.

Strumenti correlati