Generatore di timestamp Unix

Come funziona

1. Convertire una data in timestamp: inserisci una data e un'ora con il selettore, poi clicca su Genera per ottenere il timestamp Unix in secondi e millisecondi.
2. Convertire un timestamp in data: incolla un timestamp Unix (secondi o millisecondi) per riconvertirlo in data e ora leggibili.
3. Ottenere il timestamp attuale: clicca su «Adesso» per recuperare all'istante il timestamp Unix del momento presente.

Perché usare il generatore di timestamp Unix?

I timestamp Unix sono il linguaggio universale del tempo in informatica, un singolo intero che rappresenta i secondi trascorsi dal 1° gennaio 1970 (UTC). Alimentano database, API, log, token di autenticazione e pianificazione di eventi. Convertire manualmente tra timestamp e date leggibili comporta calcoli di fusi orari facili da sbagliare. Questo strumento gestisce correttamente la conversione in entrambe le direzioni, fa risparmiare tempo ed evita bug di fusi orari.

Funzionalità

• Conversione bidirezionale: data/ora → timestamp Unix e timestamp Unix → data/ora.
• Secondi e millisecondi: supporta il tempo Unix in secondi (10 cifre) come in millisecondi (13 cifre).
• Gestione dei fusi: mostra l'ora nel tuo fuso locale e in UTC per un confronto senza ambiguità.
• Pulsante ora attuale: ottieni all'istante il timestamp del momento presente.
• Visualizzazione relativa: indica da quanto tempo o tra quanto tempo (per es. «3 giorni fa»).

Domande frequenti

Cos'è un timestamp Unix?

Un timestamp Unix è il numero di secondi trascorsi dall'epoca Unix, mezzanotte UTC del 1° gennaio 1970. È una rappresentazione di un istante indipendente dai fusi, il che lo rende il formato preferito per memorizzare e confrontare istanti nei database e nelle API.

Perché JavaScript usa i millisecondi?

Date.now() e new Date().getTime() in JavaScript restituiscono millisecondi dall'epoca (un numero a 13 cifre), mentre gli strumenti Unix e la maggior parte dei database usano i secondi (10 cifre). Verifica se il tuo timestamp ha 10 o 13 cifre per sapere quale formato hai.

Come convertire un timestamp in ora locale?

Incolla il timestamp; lo strumento lo converte automaticamente al fuso locale del tuo browser. La visualizzazione mostra sia l'ora locale sia l'UTC per lavorare tra fusi con sicurezza.

Da dove viene il tempo Unix

Il tempo Unix è stato definito da Ken Thompson e Dennis Ritchie in Unix First Edition (novembre 1971). Inizialmente il kernel contava 60esimi di secondo dal 1971-01-01 in un campo a 32 bit, che traboccava dopo 2 anni 9 mesi. Con Unix Sixth Edition (1975) il conteggio è stato cambiato in secondi dal 1970-01-01 00:00:00 UTC, l'epoca che ogni sistema simile a Unix usa ancora oggi. La scelta è stata arbitraria, gli ingegneri avevano bisogno di una data tonda vicino all'era in cui lavoravano. POSIX.1 (1988) ha codificato la definizione come standard ufficiale, e POSIX.1-2017 (IEEE Std 1003.1-2017), la versione attuale, definisce ancora time_t come numero di secondi dall'epoca, con l'avvertenza che il tempo POSIX finge che i secondi intercalari non esistano. ISO 8601 (1988, attualmente 2019) ha standardizzato il formato leggibile 2026-05-13T14:30:00Z, e RFC 3339 (luglio 2002) lo ha ristretto a un profilo data-ora internet inequivocabile. Date.now() di JavaScript restituisce millisecondi dall'epoca perché la spec è stata scritta nel 1995 quando la precisione sub-secondo era già richiesta; la maggior parte dei database e delle utility Unix usa ancora secondi interi.

Il problema dell'anno 2038 (e perché conta ora)

Un time_t a 32 bit con segno può rappresentare al massimo 2.147.483.647 secondi, che arrivano alle 03:14:07 UTC di martedì 19 gennaio 2038. Un secondo dopo, il contatore si avvolge a −2.147.483.648, che la maggior parte del software interpreta come 13 dicembre 1901. È la stessa classe di bug di Y2K ma causata dalla larghezza intera, non dal formato data. La soluzione è usare time_t a 64 bit (che spinge il rollover a circa l'anno 292 miliardi). La maggior parte dei sistemi Linux a 64 bit usa già time_t a 64 bit per impostazione predefinita; Linux 5.6 (marzo 2020) ha reso disponibile time_t a 64 bit anche su architetture a 32 bit. Il rischio rimanente vive nei sistemi embedded, nei vecchi formati di file binari e nei protocolli di rete a 32 bit. Il Network Time Protocol (NTP) si avvolge già nel 2036 perché usa un contatore senza segno a 32 bit dal 1900, NTPv4 aggiunge un numero di era per estenderlo. Se distribuisci software che gestisce date, controlla il tuo stack prima del 2038, specialmente colonne SQL tipizzate come INT(11) o vecchio codice C con campi tempo long.

I formati di timestamp che incontrerai

• Secondi Unix (10 cifre). 1747143000. Il time_t POSIX classico. Usato da PostgreSQL EXTRACT(epoch FROM ...), MySQL UNIX_TIMESTAMP(), TTL Redis, claim iat/exp JWT (secondo RFC 7519), git log, e la maggior parte delle utility Unix. Sarà 11 cifre dopo novembre 2286.
• Millisecondi Unix (13 cifre). 1747143000000. Date.now() di JavaScript, System.currentTimeMillis() di Java, Kafka, Elasticsearch, e la maggior parte delle pipeline di logging moderne. Moltiplicato per 1000 il conteggio dei secondi.
• Microsecondi Unix (16 cifre) e nanosecondi (19 cifre). 1747143000000000. Usato da time.time_ns() di Python, time.Now().UnixNano() di Go, revisioni MVCC etcd e sistemi di trading ad alta frequenza dove la risoluzione di millisecondi è troppo grossolana.
• ISO 8601. 2026-05-13T14:30:00.000Z o 2026-05-13T14:30:00+02:00. Ordinabile come stringa, inequivocabile sul fuso orario, accettato praticamente da ogni API moderna. Il suffisso Z significa «tempo Zulu», un designatore NATO per UTC.
• RFC 3339. Un profilo più rigoroso di ISO 8601 usato da JSON Schema, OpenAPI, e la maggior parte delle API REST. Richiede un designatore di fuso orario e proibisce alcune funzionalità ISO 8601 come date settimanali e date ordinali.
• RFC 2822 / RFC 5322. Tue, 13 May 2026 14:30:00 +0000. Il formato dell'header email Date:. Ancora ubiquo perché SMTP gira ovunque.
• Data seriale Excel. Giorni frazionari dal 1900-01-01 (o 1904 sul classico Mac Excel). 2026-05-13 14:30 è circa 46150.6042. Excel tratta tristemente il 1900 come anno bisestile (non lo è) per compatibilità con Lotus 1-2-3.

Quando questo strumento si guadagna il pane

• Debug JWT. Il token ha "exp": 1747143000 e devi sapere se è scaduto. Incolla, vedi la data umana.
• Forensics dei log. Una linea dice timestamp=1747143012345, devi correlare con l'orario a muro di un altro strumento. 13 cifre, quindi millisecondi.
• Query del database. Vuoi trovare righe dopo una data specifica. WHERE created_at > 1747143000 richiede il valore in secondi; copialo dallo strumento.
• Fixture di test. Codificare «ieri» in un test, generi il timestamp ora e lo incolli nella spec.
• Cron / job pianificati. Verifica il valore in secondi al quale uno scheduler si attiverà, specialmente attraverso le transizioni DST.
• Replay di eventi. Gli offset Kafka e gli indici Elasticsearch spesso usano timestamp ms; converti in data per ispezionare una finestra di replay specifica.
• Invalidazione della cache. Un header Expires o If-Modified-Since in formato RFC 2822, genera il formato wire corretto per il test.

Errori che costano ore ai team

• Mescolare secondi e millisecondi. Passare un valore a 10 cifre a una funzione che si aspetta millisecondi restituisce una data del 1970, fuori di un fattore 1000. La regola 10-vs-13 cifre è il test più veloce, i valori moderni in secondi hanno 10 cifre fino al 2286, in millisecondi 13 cifre.
• Memorizzare l'ora locale. Memorizza sempre UTC; converti in locale al momento della visualizzazione. Memorizzare "2026-05-13 14:30:00" senza fuso orario si rompe nel momento in cui un server, utente o salto DST cambia l'offset locale.
• Dimenticare le transizioni DST. Le 2:30 del mattino accadono due volte durante l'ora solare. Codice ingenuo che fa start + (24 * 3600) per significare «domani» sarà fuori di un'ora due volte all'anno. Usa una vera libreria di date (luxon, date-fns-tz, zoneinfo Python) che conosce il database IANA tz.
• Assumere che il tempo POSIX conti i secondi intercalari. Non lo fa. 2016-12-31 23:59:60 è esistito nella vita reale (il 27º secondo intercalare) ma il time_t POSIX salta da 23:59:59 a 00:00:00 senza alcuna consapevolezza del secondo extra. TAI (Tempo Atomico Internazionale) conta i secondi intercalari, il tempo POSIX è offset da UTC di zero secondi.
• Memorizzare time_t in colonne INT(4). I vecchi schemi MySQL usano frequentemente INT che è 4 byte / con segno a 32 bit / si avvolge nel 2038. Migra a BIGINT o TIMESTAMP. Il tipo TIMESTAMP dei fornitori MySQL ospitati è anche 4 byte per default, controlla i docs.
• Parsing di ISO 8601 con regex. Le mezze implementazioni scartano silenziosamente il fuso orario. Usa il parser della piattaforma: new Date(s) in JavaScript, datetime.fromisoformat(s) in Python ≥ 3.11, Instant.parse(s) in Java.
• Excel converte automaticamente i timestamp. Incollare 1747143012345 in Excel senza prefissarlo con ' (un apostrofo letterale) fa sì che Excel lo legga come numero, a volte convertendolo in notazione scientifica. O formatta la colonna come Testo prima, o incolla con il prefisso apostrofo.

Altre domande frequenti

Perché è stato scelto 1970-01-01 come epoca?

Convenienza. Le prime versioni di Unix negli anni '70 volevano un'epoca che non sarebbe traboccata entro una ragionevole vita lavorativa. 1970-01-01 era una data tonda vicino all'era di sviluppo, e un contatore di secondi a 32 bit da lì raggiunge comodamente il 2038. La scelta è ora incisa in POSIX.1-2017 §4.16 ed è uno degli accordi multipiattaforma più stabili nel software. Non c'è significato inerente alla data, nessun evento storico, nessuna ancora astronomica, solo un'ancora arbitraria su cui tutti hanno concordato.

Qual è la differenza tra UTC, GMT e tempo Zulu?

Per scopi software, si riferiscono allo stesso orario a muro. UTC (Tempo Coordinato Universale) è lo standard moderno, definito dagli orologi atomici e dal BIPM. GMT (Greenwich Mean Time) è il vecchio standard astronomico britannico che era il riferimento mondiale de facto prima del cronometraggio atomico. Tempo Zulu è il designatore NATO/militare per UTC, scritto come il suffisso Z in ISO 8601 (2026-05-13T14:30:00Z). UTC e GMT possono differire fino a 0,9 secondi perché UTC è guidato per rimanere vicino a UT1 (tempo solare medio) tramite secondi intercalari, ma nessuna applicazione che non usa direttamente UT1 lo noterà.

Perché viene mostrato a volte il 1970 quando mi aspettavo qualcos'altro?

Due cause comuni. Primo, il timestamp è in millisecondi ma è stato passato a una funzione che si aspetta secondi, o viceversa, dando una data fuori di un fattore 1000. Secondo, il valore è 0 o NaN, entrambi i quali la maggior parte delle librerie di date rende come 1970-01-01T00:00:00Z. Ispeziona la larghezza intera grezza: 10 cifre è secondi, 13 è millisecondi, 16 è microsecondi, 19 è nanosecondi.

Questo strumento gestirà timestamp negativi per date prima del 1970?

Sì. new Date(-86400000) restituisce 1969-12-31T00:00:00Z. La Date di JavaScript può rappresentare qualsiasi momento da −271821-04-20 a +275760-09-13, che è circa ±100 milioni di giorni dall'epoca. Oltre quell'intervallo, l'API restituisce Invalid Date. Per date storiche, sii consapevole anche della transizione giuliano-gregoriana (1582 nei paesi cattolici, 1752 in Gran Bretagna, fino al 1923 in Grecia) dove le date del calendario sono saltate da 10 a 13 giorni; le librerie di date variano in come lo gestiscono.

I miei dati timestamp vengono inviati da qualche parte?

No. Tutta la conversione gira in JavaScript all'interno del tuo browser. La pagina non invia mai alcun valore che inserisci. Apri la scheda Rete in DevTools e converti un timestamp, vedrai zero richieste in uscita durante la conversione. Sicuro per token con claim di timestamp, righe di log interne, o qualsiasi cosa che non incolleresti in un servizio ospitato.