Convertitore da timestamp Unix a data
Converti un timestamp Unix in una data e ora leggibili — oppure converti qualsiasi data in un timestamp Unix. Supporta secondi e millisecondi.
Condividi questo strumento
Incorpora nel tuo sito
Strumenti correlati
Che cos'è un timestamp Unix?
Un timestamp Unix, chiamato anche Unix time o POSIX time, è il numero di secondi trascorsi da 1970-01-01 00:00:00 UTC, noto come Unix epoch. È uno standard molto usato in informatica perché rappresenta un istante nel tempo come un singolo numero intero, rendendo archiviazione, confronto e calcoli molto semplici.
JavaScript lavora internamente in millisecondi, quindi Date.now() restituisce il timestamp Unix moltiplicato per 1000. Molte API, database e sistemi backend usano invece i secondi. Questo strumento accetta entrambi i formati e rileva automaticamente se hai inserito secondi o millisecondi in base alla dimensione del numero.
Timestamp Unix notevoli
| Timestamp | Data (UTC) | Nota |
|---|---|---|
0 | 1970-01-01 00:00:00 | Unix epoch |
1,000,000,000 | 2001-09-09 01:46:40 | 1 miliardo di secondi |
2,000,000,000 | 2033-05-18 03:33:20 | 2 miliardi di secondi |
2,147,483,647 | 2038-01-19 03:14:07 | Problema del 2038 (max 32-bit) |
Perché il 1970?
L'Unix epoch del 1° gennaio 1970 è stata scelta in parte per convenzione e in parte per vincoli pratici. Unix è stato sviluppato tra la fine degli anni '60 e l'inizio degli anni '70 ai Bell Labs. Gli sviluppatori avevano bisogno di una data di inizio recente e “rotonda” per la rappresentazione del tempo. Il 1° gennaio 1970 era abbastanza recente da essere pratico e non aveva alcun significato tecnico speciale — era semplicemente un punto di ancoraggio comodo.
Esistono date di epoch alternative in altri sistemi: l'epoch di Windows FILETIME è il 1° gennaio 1601; il tempo GPS è iniziato il 6 gennaio 1980; l'epoch NTP è il 1° gennaio 1900. Quando si converte tra sistemi, conoscere l'epoch di ciascuno è essenziale.
Secondi vs millisecondi
Il timestamp Unix originale è in secondi. La maggior parte dei linguaggi e sistemi lato server (shell Unix, time.time() di Python, time() di PHP, la maggior parte dei database) usa i secondi. Date.now() e new Date().getTime() di JavaScript restituiscono millisecondi. Questa differenza è una fonte comune di bug quando i frontend JavaScript comunicano con API backend.
Un timestamp Unix in secondi oggi è un numero a 10 cifre (circa 1.700.000.000 nel 2023). Un timestamp in millisecondi è un numero a 13 cifre. Il calcolatore rileva quale formato hai inserito in base al numero di cifre e converte di conseguenza.
Il problema del 2038
I sistemi che memorizzano i timestamp Unix come intero signed a 32 bit possono rappresentare date solo fino a 2,147,483,647 secondi dopo l'epoch — cioè le 03:14:07 UTC del 19 gennaio 2038. Dopo quel momento, un intero signed a 32 bit va in overflow e diventa un grande numero negativo, rappresentando una data nel 1901.
Questo è talvolta chiamato problema "Y2K38" o Unix Millennium Bug. I moderni sistemi a 64 bit non sono interessati, perché un intero signed a 64 bit può rappresentare timestamp per circa 292 miliardi di anni. Tuttavia, sistemi embedded, database legacy e vecchi software a 32 bit possono essere ancora vulnerabili. Molti settori — tra cui telecomunicazioni, banche e sistemi di controllo industriale — hanno programmi di migrazione in corso per affrontare questo problema.
Come ottenere il timestamp Unix corrente
| Linguaggio / ambiente | Comando |
|---|---|
| JavaScript | Math.floor(Date.now() / 1000) |
| Python | import time; int(time.time()) |
| PHP | time() |
| Bash | date +%s |
| SQL (PostgreSQL) | EXTRACT(EPOCH FROM NOW())::int |
| SQL (MySQL) | UNIX_TIMESTAMP() |
| Go | time.Now().Unix() |
| Rust | SystemTime::now().duration_since(UNIX_EPOCH).unwrap().as_secs() |
Usi pratici
Sviluppo API: le REST API usano spesso i timestamp Unix per created_at, updated_at e campi di scadenza dei token. Un timestamp è indipendente dal fuso orario e non ambiguo — a differenza delle stringhe di data formattate, che dipendono da locale e convenzioni di formattazione.
Scadenza token: i JWT (JSON Web Tokens) usano timestamp Unix per le claim exp (scadenza) e iat (emissione). Un token scade quando il timestamp corrente supera il valore exp. Calcolare la scadenza — “questo token deve scadere tra 24 ore” — richiede aggiungere 86.400 secondi al timestamp corrente.
Cache TTL: la scadenza della cache è spesso impostata come timestamp Unix o come numero di secondi da adesso. Per fare debug di problemi di cache è spesso necessario convertire un timestamp di scadenza salvato in una data leggibile.
Analisi log: i log dei server includono spesso timestamp Unix. Convertirli in date leggibili è il primo passo per correlare le righe di log con eventi reali.
Archiviazione database: memorizzare timestamp come interi invece che come stringhe formattate evita bug di conversione del fuso orario e semplifica ordinamento, query per intervalli e calcoli. Una query per “tutti i record degli ultimi 7 giorni” diventa WHERE created_at > (NOW_UNIX - 604800).
Articoli correlati
Come usare i timestamp Unix per query su intervalli di dateLe query su intervalli di date sono tra le operazioni più comuni nei database. Usare timestamp Unix le rende più veloci, più semplici e sicure rispetto ai fusi orari. Ecco come farlo correttamente.
Unix Timestamps nella cache e TTL — Come funzionano realmente i tempi di scadenzaLa scadenza della cache, i valori TTL e la logica di invalidazione dipendono tutti dai timestamp Unix. Ecco come i sistemi di cache utilizzano i timestamp, come risolvere i problemi di cache stale e cosa può andare male.
Ora Unix nelle API e nei Log Spiegata Bene: Come Leggerla e Convertirla CorrettamenteL'ora Unix compare ovunque nelle API, nei database e nei log, ma è facile fraintenderla. Questa guida spiega cosa significa l'ora Unix, perché i sistemi la usano e come convertirla senza errori comuni.