Perché il 1° gennaio 1970?

I Bell Labs scelsero questa data tonda e recente quando Unix v1 fu rilasciato nel 1971. Le versioni precedenti del prototipo usavano il 1971-01-01 con tick da 1/60 di secondo; il rollover di un contatore a 32 bit sarebbe avvenuto in circa 2,3 anni, quindi il team passò a secondi interi e retrodatò l'epoch al 1970-01-01 UTC. Fu una scelta pratica, non teologica.

I secondi intercalari (leap seconds) sono contati nel tempo Unix?

No. POSIX definisce un timestamp Unix come il numero di secondi dall'epoch assumendo esattamente 86.400 secondi al giorno, ogni giorno. L'UTC reale ha occasionalmente inserito un secondo intercalare (più di recente il 30 giugno 2017). La maggior parte dei sistemi gestisce questo congelando il contatore per un secondo o distribuendo il secondo intercalare su un intervallo più lungo (l'approccio di Google). Il risultato: lo stesso timestamp Unix può corrispondere a due istanti reali diversi durante un secondo intercalare positivo.

Cosa si rompe esattamente nel 2038?

Il 19 gennaio 2038 alle 03:14:07 UTC, un contatore con segno a 32 bit va in overflow diventando un numero negativo che rappresenta il 13 dicembre 1901. Qualsiasi sistema a 32 bit, dispositivo embedded, formato di file o colonna di database che usa un int32 con segno per il tempo si romperà. Linux a 64 bit ha migrato anni fa; l'esposizione rimanente è nei sistemi embedded, nei formati di file legacy (timestamp degli inode ext2/3, timestamp DOS ZIP) e nelle colonne SQL di tipo INT esplicito.

Dovrei memorizzare i timestamp come interi o come stringhe ISO 8601?

Interi se farai aritmetica e le dimensioni di archiviazione contano. Stringhe ISO 8601 se gli esseri umani leggeranno i dati o se è necessario preservare il fuso orario originale. Molti sistemi memorizzano entrambi: epoch ms UTC per ordinamento e aritmetica, più la stringa ISO originale con fuso orario per audit. Non memorizzare numeri epoch in ora locale; nel momento in cui un server cambia fuso orario i dati sono silenziosamente corrotti.

Qual è la differenza tra secondi, millisecondi, microsecondi e nanosecondi?

È solo una questione di scala. Date.now() di JavaScript è in millisecondi dall'epoch. Le syscall Unix come clock_gettime(CLOCK_REALTIME) tipicamente restituiscono nanosecondi. I tipi TIMESTAMP dei database variano per fornitore: Postgres usa microsecondi, MySQL DATETIME(6) usa microsecondi, SQL Server usa tick da 100ns. Documentate sempre l'unità al confine dell'API.

Un timestamp Unix è consapevole del fuso orario?

Sì e no. Il timestamp stesso è un conteggio assoluto di secondi da un istante UTC fisso, quindi è inequivocabile. Ma non porta informazioni sul fuso orario di visualizzazione: la conversione a una data del calendario richiede la scelta di un fuso orario. Un timestamp di 1700000000 è lo stesso momento fisico ovunque, ma si mostra come 14 novembre a Tokyo e 13 novembre a Los Angeles.

Guide

Unix Timestamp Spiegato: Epoch, Precisione e il Problema dell'Anno 2038

Il formato temporale più diffuso al mondo è un trucco di 56 anni con una miccia di 12 anni.

By Buğra SözeriPublished May 31, 2026

Un timestamp Unix è un singolo intero che fissa un momento nel tempo. È il formato temporale più utilizzato nell’informatica: ogni database, riga di log, JWT e cookie HTTP alla fine si basa su di esso. È anche pieno di insidie che non si annunciano finché i dati non sono già sbagliati.

Cos’è, con precisione

Un timestamp Unix è il numero di secondi (o millisecondi, microsecondi, nanosecondi — scegliere un’unità) trascorsi dal 1970-01-01T00:00:00 UTC, comunemente chiamato “Unix epoch”. Oggi si tratta di un numero nell’ordine degli 1,7 miliardi per i secondi, o 1,7 trilioni per i millisecondi.

È possibile convertire un timestamp da e verso una data del calendario con il nostro convertitore di timestamp: incollate qualsiasi intero e vedrete la data UTC, la data locale e il tempo relativo.

Perché il 1970?

La scelta non è profonda. I Bell Labs rilasciarono Unix v1 nel 1971 e avevano bisogno di una data recente arbitraria per il contatore del tempo. Un prototipo precedente contava tick da 1/60 di secondo a partire dal 1971-01-01, ma il contatore a 32 bit sarebbe andato in overflow in meno di 2,5 anni. Il team passò a secondi interi e retrodatò l’epoch al 1970-01-01 in modo che le date degli anni precedenti potessero essere rappresentate come numeri negativi. Rimase così perché ogni sistema a valle lo consolidò.

Precisione: secondi, ms, μs, ns

Diversi strati dello stack usano unità diverse:

Secondi — Unix classico time(), claims JWT iat/exp, header HTTP Date, la maggior parte delle esportazioni dei fogli di calcolo.
Millisecondi — JavaScript Date.now(), Java System.currentTimeMillis(), timestamp dei record Kafka, MongoDB ObjectId (i primi 4 byte sono secondi-dall’epoch, impacchettati insieme ad altri campi in BSON).
Microsecondi — Postgres TIMESTAMP, MySQL DATETIME(6), librerie di tracing (Jaeger, OpenTelemetry).
Nanosecondi — Linux clock_gettime(CLOCK_REALTIME), Go time.Now().UnixNano(), etcd, recenti esportatori OpenTelemetry.

A un confine API, non dare mai nulla per scontato. 1700000000è novembre 2023 se letto come secondi, gennaio 1970 più 20 giorni se letto come millisecondi. Una rapida euristica: se l’intero ha circa 10 cifre, sono secondi; 13 cifre, millisecondi; 16 cifre, microsecondi; 19 cifre, nanosecondi. Il nostro strumento timestamp rileva automaticamente tutti e quattro.

Secondi intercalari: la bugia alla base

POSIX definisce un timestamp Unix come “secondi dall’epoch” assumendo esplicitamente che ogni giorno abbia 86.400 secondi. L’UTC reale non lo fa. Dal 1972, sono stati inseriti 27 secondi intercalari positivi per mantenere l’UTC allineato con la rotazione della Terra. Il più recente è stato il 30 giugno 2017.

Il comportamento POSIX rigoroso è di congelare l’orologio durante un secondo intercalare: il timestamp 1483228827viene servito per due secondi consecutivi. Questo rompe la monotonicità e manda in crash qualsiasi cosa che assuma l’unicità dei timestamp. L’alternativa di Google, il “leap smearing”, distribuisce il secondo extra su una finestra di 24 ore così che nessun secondo individuale venga ripetuto; AWS, Meta e Microsoft fanno lo stesso. Due server che usano schemi diversi possono dissentire fino a mezzo secondo attorno a un evento intercalare.

Per il 99% delle applicazioni questo non ha importanza. Per qualsiasi cosa che ordini eventi con precisione sub-secondo tra più provider, assolutamente sì.

Il problema dell’anno 2038

Un intero con segno a 32 bit può contenere valori da −2.147.483.648 a +2.147.483.647. Interpretato come secondi dal 1970-01-01 UTC, il limite superiore è 2038-01-19T03:14:07Z. Un secondo dopo, il contatore va in overflow al valore più negativo, rappresentando il 13 dicembre 1901.

I moderni sistemi operativi a 64 bit usano già time_ta 64 bit, che non va in overflow per altri 292 miliardi di anni. L’esposizione rimanente:

Dispositivi embedded — ECU automotive, PLC industriali, impianti medicali. Molti usano ancora il tempo a 32 bit e non vengono aggiornati.
Formati di file — timestamp degli inode ext2/ext3, ZIP classico (formato DOS), vecchi attributi estesi NTFS.
Colonne SQL — una colonna dichiarata INTper “risparmiare spazio” per i secondi epoch. Verificate i vostri schemi ora, non nel 2037.
Codice C legacy compilato contro una vecchia libc su ARM a 32 bit. La migrazione al time_ta 64 bit è una rottura ABI e molti produttori non l’hanno ancora rilasciata.

Per un trattamento più approfondito, consultate la nostra voce del glossario Unix timestamp.

Tempo Unix vs ISO 8601

ISO 8601 (e il suo profilo Internet, RFC 3339) scrive il tempo come 2026-05-31T14:30:00Z. È leggibile dall’uomo, consapevole del fuso orario e auto-descrittivo. Il tempo Unix è compatto, ordinabile come intero e inequivocabile sull’istante effettivo — ma non dice nulla su quale fuso orario chi ha scritto intendeva per la visualizzazione.

Usate ISO 8601 nelle API, nei log e ovunque un essere umano leggerà il valore. Usate gli interi Unix nell’archiviazione quando spazio e aritmetica contano, o quando l’ordinamento deve essere economico. Molti sistemi portano entrambi: l’intero per le operazioni, la stringa per le tracce di audit. Consultate la voce del glossario ISO 8601 per la grammatica completa.

Insidie comuni

Parsing senza fuso orario

new Date("2026-05-31") in JavaScript viene analizzato come mezzanotte UTC, ma new Date("2026-05-31 14:00") (notare lo spazio, non una T) viene analizzato come ora locale sulla maggior parte dei motori. I timestamp Unix risultanti differiscono del vostro offset. Includete sempre il designatore di fuso orario (Z, +09:00) sugli input che non controllate completamente.

Mischiare le unità silenziosamente

Un microservizio che emette millisecondi parla con un downstream che si aspetta secondi. Il downstream vede timestamp nell’anno 55000 e li scrive silenziosamente nel database. Validate sempre la grandezza dei timestamp in arrivo rispetto a un intervallo plausibile.

Epoch in ora locale

Alcuni sistemi legacy calcolano “secondi dal 1970-01-01 ora locale”. Questo non è il tempo Unix e si rompe nel momento in cui un server viene spostato o l’ora legale cambia. Se ereditate uno di questi, registrate l’offset accanto all’intero e convertite al vero epoch UTC al confine.

Provate il convertitore

Incollate qualsiasi intero nel nostro convertitore di timestamp per vedere le interpretazioni UTC e locale fianco a fianco, con rilevamento automatico di secondi/ms/μs/ns. Per la conversione in batch o controlli di precisione extra, lo strumento timestamp datetime gestisce entrambe le direzioni.

Conclusione

Il tempo Unix è un ottimo default perché è compatto, ordinabile e inequivocabile sull’istante. È un pessimo default nel momento in cui dimenticate in quale unità siete, quale fuso orario intendete visualizzare, o se la vostra archiviazione è a 32 bit. L’epoch era una scelta pragmatica nel 1970; la scogliera del 2038 è il conto che arriva. Verificate le vostre colonne intere, documentate le vostre unità e non memorizzate epoch in ora locale.

Frequently asked questions

Perché il 1° gennaio 1970?: I Bell Labs scelsero questa data tonda e recente quando Unix v1 fu rilasciato nel 1971. Le versioni precedenti del prototipo usavano il 1971-01-01 con tick da 1/60 di secondo; il rollover di un contatore a 32 bit sarebbe avvenuto in circa 2,3 anni, quindi il team passò a secondi interi e retrodatò l'epoch al 1970-01-01 UTC. Fu una scelta pratica, non teologica.
I secondi intercalari (leap seconds) sono contati nel tempo Unix?: No. POSIX definisce un timestamp Unix come il numero di secondi dall'epoch assumendo esattamente 86.400 secondi al giorno, ogni giorno. L'UTC reale ha occasionalmente inserito un secondo intercalare (più di recente il 30 giugno 2017). La maggior parte dei sistemi gestisce questo congelando il contatore per un secondo o distribuendo il secondo intercalare su un intervallo più lungo (l'approccio di Google). Il risultato: lo stesso timestamp Unix può corrispondere a due istanti reali diversi durante un secondo intercalare positivo.
Cosa si rompe esattamente nel 2038?: Il 19 gennaio 2038 alle 03:14:07 UTC, un contatore con segno a 32 bit va in overflow diventando un numero negativo che rappresenta il 13 dicembre 1901. Qualsiasi sistema a 32 bit, dispositivo embedded, formato di file o colonna di database che usa un int32 con segno per il tempo si romperà. Linux a 64 bit ha migrato anni fa; l'esposizione rimanente è nei sistemi embedded, nei formati di file legacy (timestamp degli inode ext2/3, timestamp DOS ZIP) e nelle colonne SQL di tipo INT esplicito.
Dovrei memorizzare i timestamp come interi o come stringhe ISO 8601?: Interi se farai aritmetica e le dimensioni di archiviazione contano. Stringhe ISO 8601 se gli esseri umani leggeranno i dati o se è necessario preservare il fuso orario originale. Molti sistemi memorizzano entrambi: epoch ms UTC per ordinamento e aritmetica, più la stringa ISO originale con fuso orario per audit. Non memorizzare numeri epoch in ora locale; nel momento in cui un server cambia fuso orario i dati sono silenziosamente corrotti.
Qual è la differenza tra secondi, millisecondi, microsecondi e nanosecondi?: È solo una questione di scala. Date.now() di JavaScript è in millisecondi dall'epoch. Le syscall Unix come clock_gettime(CLOCK_REALTIME) tipicamente restituiscono nanosecondi. I tipi TIMESTAMP dei database variano per fornitore: Postgres usa microsecondi, MySQL DATETIME(6) usa microsecondi, SQL Server usa tick da 100ns. Documentate sempre l'unità al confine dell'API.
Un timestamp Unix è consapevole del fuso orario?: Sì e no. Il timestamp stesso è un conteggio assoluto di secondi da un istante UTC fisso, quindi è inequivocabile. Ma non porta informazioni sul fuso orario di visualizzazione: la conversione a una data del calendario richiede la scelta di un fuso orario. Un timestamp di 1700000000 è lo stesso momento fisico ovunque, ma si mostra come 14 novembre a Tokyo e 13 novembre a Los Angeles.

Published May 31, 2026