Convertitore Timestamp Unix

Converti qualsiasi timestamp Unix in una data e ora leggibili.

Il nostro convertitore:

• rileva automaticamente secondi (10 cifre) e millisecondi (13 cifre)
• mostra l'ora UTC e locale
• visualizza molteplici formati, inclusi ISO 8601 e RFC 2822

Converti qualsiasi data e ora nel relativo timestamp Unix.

Seleziona una data, scegli il fuso orario e ottieni il tempo Epoch sia in secondi che in millisecondi.

Perfetto per:

• sviluppo di API
• query su database
• risoluzione di problemi legati al tempo

Il tempo Unix è un sistema per tracciare un istante preciso esprimendolo come numero di secondi trascorsi dall'Epoch Unix, definito come le 00:00:00 UTC del 1° gennaio 1970. L'IEEE e The Open Group lo codificano nello standard POSIX (IEEE Std 1003.1), in cui viene definito formalmente "Seconds Since the Epoch".

Una sottigliezza fondamentale documentata da POSIX è che il tempo Unix ignora volutamente i secondi intercalari (leap seconds), trattando ogni giorno come un intervallo di esattamente 86.400 secondi. Poiché il valore è un singolo numero intero indipendente dai fusi orari, risulta privo di ambiguità su qualsiasi sistema.

Memorizzare l'ora come un numero intero, come evidenziato da MDN Web Docs per l'oggetto Date di JavaScript, rende il calcolo e i confronti estremamente semplici rispetto all'analisi di stringhe di data formattate.

Un timestamp Unix a 10 cifre conta i secondi trascorsi dall'Epoch, mentre un timestamp a 13 cifre conta i millisecondi: confondere queste due unità è l'errore di conversione più comune.

Come indicato su MDN Web Docs, le funzioni JavaScript Date.now() e getTime() restituiscono millisecondi, motivo per cui 1700000000000 è un valore JS valido. Al contrario, le funzioni C POSIX come time(), l'equivalente time.time() in Python, la maggior parte dei database SQL e il comando Bash date +%s operano in secondi (1700000000).

Per convertire tra le due unità, moltiplica i secondi per 1.000 o dividi i millisecondi per 1.000.

Il nostro convertitore rileva automaticamente l'unità in base al numero di cifre, ma quando scrivi del codice dovresti sempre verificare quale unità si aspetta il tuo linguaggio o la tua API per evitare date che finiscono nel 1970 o tra migliaia di anni nel futuro.

Puoi generare il timestamp Unix corrente con un'unica chiamata in quasi tutti i linguaggi di programmazione.

• In JavaScript, MDN Web Docs raccomanda Math.floor(Date.now() / 1000) per i secondi o Date.now() per i millisecondi.
• In Python, time.time() restituisce un float di secondi dall'Epoch, rispecchiando la funzione time() della libreria C definita da POSIX.
• Da riga di comando, date +%s di GNU coreutils stampa il timestamp corrente con precisione al secondo, mentre PHP usa time() e Go usa time.Now().Unix().
• I motori SQL mettono a disposizione funzioni quali UNIX_TIMESTAMP() in MySQL ed EXTRACT(EPOCH FROM now()) in PostgreSQL.

Tutti questi metodi fanno riferimento alla medesima origine del 1970 UTC, quindi i valori sono direttamente intercambiabili una volta normalizzata l'unità di misura tra secondi e millisecondi.

Utilizza un timestamp Unix per il salvataggio dei dati e il calcolo, e ISO 8601 per lo scambio di dati leggibili e i log.

ISO 8601 è lo standard internazionale per la rappresentazione di date e ore sotto forma di stringhe come 2023-11-14T22:13:20Z, dove la T maiuscola separa la data dall'ora e la Z finale indica l'ora UTC (Zulu time). Queste lettere sono sensibili al maiuscolo/minuscolo, quindi se stai riordinando stringhe copiate da fonti miste, un rapido passaggio in un convertitore di maiuscole/minuscole le mantiene analizzabili. Lo standard RFC 3339 dell'IETF adatta ISO 8601 per l'uso su Internet ed è quello adottato dalla maggior parte delle API JSON per i campi di data, dal momento che JSON stesso (RFC 8259) non possiede un tipo di dati nativo per le date.

Un numero intero Unix è più compatto e indipendente dalla localizzazione, ma non è autoesplicativo, mentre una stringa ISO 8601 è immediatamente leggibile. Molti sistemi memorizzano l'intero internamente e lo serializzano in ISO 8601 nell'interfaccia dell'API per sfruttare i vantaggi di entrambi.

Un timestamp Unix non ha fuso orario perché fa sempre riferimento a un singolo istante misurato dall'Epoch in UTC. I fusi orari diventano rilevanti solo nel momento in cui quell'istante viene mostrato all'utente sotto forma di data e ora locale.

Il database IANA Time Zone Database (o tz database) è la fonte autorevole utilizzata dai sistemi operativi e dai linguaggi di programmazione per associare un istante all'ora locale, comprese le regole storiche sull'ora legale.

La prassi migliore, raccomandata da MDN Web Docs e da innumerevoli guide tecniche, consiste nel memorizzare e trasmettere i timestamp in UTC, convertendoli nel fuso orario locale dell'utente solo in fase di visualizzazione. Ciò elimina ogni ambiguità legata ai cambi dell'ora legale e rende i confronti tra regioni diverse affidabili e riproducibili.

Il problema dell'anno 2038 è il momento in cui gli interi a 32 bit con segno usati per memorizzare l'ora Unix andranno in overflow, evento che si verificherà alle 03:14:07 UTC del 19 gennaio 2038.

Un valore a 32 bit con segno raggiunge un massimo di 2.147.483.647 secondi; un secondo dopo passa a un numero negativo molto elevato, che un codice ingenuo interpreta come dicembre 1901. Questo ricorda le storiche preoccupazioni legate al problema dell'anno 2000, ma ha origine nella dimensione fissa del tipo time_t in C sulle piattaforme datate.

I sistemi operativi e i linguaggi moderni sono in gran parte passati al tipo time_t a 64 bit, spostando l'overflow a circa 292 miliardi di anni nel futuro. I sistemi embedded e i vecchi formati di file rimangono le principali aree a rischio che gli sviluppatori dovrebbero verificare.

I timestamp Unix costituiscono la spina dorsale della gestione del tempo nei sistemi backend, nei log e nelle API, poiché consentono di ordinare, calcolare differenze e confrontare dati come semplici interi.

I database memorizzano le colonne created_at e updated_at come valori epoch o tipi timestamp da essi derivati, mentre i livelli di cache utilizzano i timestamp di scadenza per invalidare le voci. Anche i token di sicurezza si basano su di essi: lo standard JWT, RFC 7519, definisce i claim exp (scadenza) e iat (emissione) come valori NumericDate, che sono letteralmente i secondi trascorsi dall'epoch Unix.

I log distribuiti e gli stream di eventi utilizzano i timestamp per stabilire l'ordine cronologico, mentre i sistemi di rate limiting confrontano l'epoch attuale con le finestre temporali memorizzate. La loro indipendenza dal linguaggio li rende ideali per scambiare informazioni temporali tra servizi diversi.

I timestamp Unix negativi rappresentano istanti precedenti all'epoch, per cui -86400 corrisponde al 31 dicembre 1969 alle 00:00:00 UTC. La definizione POSIX consente valori negativi per il conteggio dei secondi e linguaggi come JavaScript rispettano questo comportamento: MDN Web Docs documenta che l'oggetto Date accetta valori di millisecondi negativi per esprimere date antecedenti al 1970.

Questo risulta utile per dati storici, date di nascita o archivi documentali.

Tuttavia, occorre prestare attenzione al fatto che alcuni sistemi più datati, database e strumenti a 32 bit trattano il tempo Unix come privo di segno o rifiutano input negativi, bloccando silenziosamente il valore all'epoch o generando un errore. Quando si gestiscono date storiche, è importante verificare che ogni livello del proprio stack, dal tipo di colonna del database alla libreria client, supporti timestamp con segno.

• L'errore più frequente è confondere i secondi con i millisecondi, il che produce date sfasate di decenni o bloccate al 1970. Verifica sempre l'unità di misura utilizzata dalla sorgente prima di convertire, poiché JavaScript restituisce millisecondi mentre la maggior parte dei backend utilizza i secondi.
• Un altro errore comune è presumere che un timestamp contenga un fuso orario; non è così, quindi applicare due volte un offset locale porta a orari errati.
• Altri problemi includono l'ignorare il limite dell'anno 2038 nei campi a 32 bit e l'aspettarsi che il tempo Unix tenga conto dei secondi bisestili, che POSIX esclude esplicitamente.
• Infine, evita di analizzare manualmente le stringhe di data formattate; utilizza le librerie standard e preferisci ISO 8601 (RFC 3339) per lo scambio dati, come consigliato da MDN Web Docs, per evitare formati ambigui come MM/DD rispetto a DD/MM.