In breve: un timestamp Unix è il numero di secondi trascorsi dalla mezzanotte UTC del 1° gennaio 1970. Log e API lo usano perché è privo di ambiguità e indipendente dal fuso orario. Le due cose che confondono sono distinguere i secondi dai millisecondi e ricordare che il numero grezzo è sempre in UTC finché non lo converti in un fuso locale.
Quando confronti voci tra server diversi, un intero è più facile da ragionare di una data formattata: nessun fuso orario, nessuna localizzazione, nessuna ambiguità dell'ora legale. Ma proprio quella crudezza è la ragione per cui un timestamp vagante può essere letto male.
Perché i timestamp partono dal 1970
L'epoca Unix è la mezzanotte UTC del 1° gennaio 1970, scelta dai primi sviluppatori Unix ai Bell Labs come punto di riferimento semplice e fisso. Ogni timestamp Unix è solo il conteggio dei secondi trascorsi da quel momento, il che rende l'aritmetica — «quanto tempo tra questi due eventi?» — una semplice sottrazione.
Secondi o millisecondi?
È l'errore più comune nel leggere i log. Una regola pratica: se il valore ha più di 11 cifre (superiore a circa 10¹¹), è quasi certamente in millisecondi. Un timestamp attuale in secondi è circa 1,7 miliardi (dieci cifre); lo stesso istante in millisecondi è circa 1,7 mila miliardi (tredici cifre). Passa un valore in millisecondi a un parser basato sui secondi e finirai decine di migliaia di anni nel futuro.
Il timestamp è sempre in UTC
Un timestamp Unix codifica un istante assoluto, non un'ora locale da orologio. Per mostrarlo a un umano applichi un fuso orario: lo stesso numero è «14:30 a Londra» e «09:30 a New York». Convertire in entrambe le direzioni in modo pulito significa essere espliciti sul fuso: un buon convertitore usa il database standard dei fusi IANA e l'API Intl.DateTimeFormat così l'offset (ora legale compresa) è corretto per quella data.
ISO 8601 per tutto ciò che archivi o condividi
Quando un timestamp deve essere leggibile da un umano e comunque sicuro per la macchina, usa l'ISO 8601: 2024-03-15T14:30:00.000Z. La T separa data e ora e la Z indica UTC. Si ordina correttamente come testo semplice e rimuove il dubbio secondi-vs-millisecondi per chi lo legge dopo.
La nota sul 2038
I sistemi che memorizzano il timestamp come intero con segno a 32 bit vanno in overflow il 19 gennaio 2038. La maggior parte delle piattaforme moderne è passata al tempo a 64 bit, ma è utile saperlo quando incontri un sistema vecchio o una colonna di database a larghezza fissa.
Un flusso pratico
- Copia il valore grezzo dal tuo log o dalla risposta dell'API.
- Incollalo nel Convertitore di Timestamp, che rileva in automatico secondi vs millisecondi e mostra la data nel fuso scelto.
- Converti entrambi gli eventi che confronti nello stesso fuso (o tieni entrambi in UTC) prima di sottrarre.
- Archivia o condividi il risultato come ISO 8601 per evitare di reintrodurre ambiguità. Abbinalo al Contatore di Caratteri se stai ripulendo un estratto di log per un ticket.
Errori comuni da evitare
- Mischiare secondi e millisecondi nello stesso confronto.
- Dare per scontato che un timestamp grezzo sia già in ora locale.
- Confrontare due eventi resi in fusi orari diversi.
- Usare campi di tempo a 32 bit a larghezza fissa che non sopravvivono al 2038.