Il tempo epoch spiegato: cos'è il timestamp Unix zero?

Cosa rappresenta il timestamp Unix 0

Ogni timestamp Unix conta il tempo trascorso da un unico punto di riferimento: il 1° gennaio 1970 alle 00:00:00 UTC. Nella definizione originale di Unix l'unità è il secondo, quindi il timestamp 0 è esattamente la mezzanotte UTC del 1° gennaio 1970 e il timestamp 86400 esattamente 24 ore dopo. I sistemi moderni usano anche millisecondi, microsecondi e nanosecondi, ma il punto di riferimento è lo stesso. Ogni valore positivo rappresenta un momento dopo l'epoch; ogni valore negativo, uno precedente.

Perché il 1° gennaio 1970?

La data fu scelta dagli sviluppatori Unix ai Bell Labs nei primi anni '70 come punto di riferimento pratico, poco prima della creazione di Unix stesso. Doveva essere abbastanza precoce perché i timestamp di sistema normali fossero positivi, abbastanza recente da rientrare nei piccoli intervalli di interi dei primi computer, e abbastanza semplice da verificare a mente. Quando Unix divenne influente, linguaggi, sistemi operativi, database, formati di log e protocolli di rete ereditarono lo stesso punto di partenza.

• Unix fu sviluppato ai Bell Labs a partire dal 1969 — l'epoch fu fissato poco prima
• Il 1° gennaio fu scelto come confine di calendario pulito
• Il 1970 anziché il 1969 perché l'implementazione usava un contatore che partiva da zero
• Ogni SO, linguaggio e protocollo moderno ha ereditato questo epoch — non esiste uno standard concorrente

Timestamp negativi: date prima del 1970

I timestamp Unix negativi rappresentano momenti prima del 1° gennaio 1970 00:00:00 UTC. La maggior parte dei sistemi moderni a 64 bit li gestisce correttamente, utile per dati storici, date di nascita, archivi e interoperabilità con sistemi i cui epoch iniziano prima di quello di Unix. Le vecchie librerie e i vecchi database possono rifiutare i valori negativi, quindi i dataset storici meritano un controllo di compatibilità esplicito.

• -1 = December 31, 1969 23:59:59 UTC (one second before the epoch)
• -86400 = December 31, 1969 00:00:00 UTC (one day before the epoch)
• -2208988800 = January 1, 1900 00:00:00 UTC
• JavaScript: new Date(-86400 * 1000).toISOString() → '1969-12-31T00:00:00.000Z'

Limiti pratici del formato

L'epoch Unix in sé non è il limite; lo è il tipo di archiviazione. Un timestamp salvato in un intero con segno a 32 bit cede molto prima di uno salvato in un intero a 64 bit, un numero JavaScript o un tipo timestamp nativo di database. Nel valutare la sicurezza di un timestamp, chiediti sia quale unità è usata sia quale tipo numerico lo memorizza.

• 32-bit signed integer max: 2,147,483,647 = January 19, 2038 03:14:07 UTC (the Year 2038 problem)
• JavaScript Date max: 8,640,000,000,000,000 ms = September 13, 275760 CE
• 64-bit signed integer max: ~9.2 × 10^18 seconds = year ~292 billion
• PostgreSQL TIMESTAMPTZ max: January 1, 294276 CE

Gli epoch di altri sistemi

Unix non è l'unico epoch usato in informatica. Altri sistemi hanno definito i propri punti di riferimento per ragioni storiche o tecniche.

• Epoch GPS: 6 gennaio 1980 00:00:00 UTC — usato da satelliti e ricevitori GPS
• Windows FILETIME: 1° gennaio 1601 00:00:00 UTC — intervalli di 100 nanosecondi
• Apple Cocoa / NSDate: 1° gennaio 2001 00:00:00 UTC
• Excel / Lotus 1-2-3: 1° gennaio 1900 — con un bug di anno bisestile deliberato per compatibilità con Lotus
• File system FAT: 1° gennaio 1980 00:00:00 ora locale

Secondi, millisecondi, microsecondi e nanosecondi epoch

La parola timestamp non indica sempre l'unità. I secondi Unix sono comuni nei sistemi operativi e nei linguaggi backend. I millisecondi Unix sono comuni in JavaScript e nelle API del browser. Microsecondi e nanosecondi compaiono nei database, nei sistemi di tracing e nei log ad alta risoluzione. L'unità controlla sia la precisione sia il numero di cifre che vedi.

• Seconds: 1700000000 — common in Python, PHP, Go, Ruby, C, and Unix command-line tools
• Milliseconds: 1700000000000 — common in JavaScript Date and many web analytics systems
• Microseconds: 1700000000000000 — common in some databases and event pipelines
• Nanoseconds: 1700000000000000000 — common in high-resolution tracing and systems languages
• Always document the unit when storing epoch values in APIs, CSV files, and database columns

Tempo epoch vs UTC vs ora locale

Il tempo epoch è un conteggio. UTC è lo standard di tempo globale che definisce il momento di riferimento. L'ora locale è una scelta di visualizzazione basata su un fuso come America/New_York o Asia/Tokyo. Un timestamp Unix non cambia quando un utente viaggia; cambiano solo la data di calendario e l'ora formattate.

• Lo stesso timestamp può apparire come date locali diverse in fusi diversi
• L'output UTC è il migliore per log, API e debug tra server
• L'output locale è il migliore per calendari, interfacce e report
• Gli offset di fuso si applicano in fase di formattazione, non vengono memorizzati nel timestamp Unix

FAQ sul tempo epoch

Il tempo epoch è sempre in secondi?

Il timestamp Unix classico è in secondi dal 1970-01-01 00:00:00 UTC, ma molti sistemi usano millisecondi, microsecondi o nanosecondi con lo stesso epoch.

I timestamp Unix possono rappresentare date prima del 1970?

Sì. I timestamp negativi rappresentano date prima dell'epoch Unix, anche se vecchie librerie e database potrebbero non supportarli.

Un timestamp Unix include un fuso orario?

No. Un timestamp Unix rappresenta un istante in UTC. Le informazioni sul fuso si usano solo quando si converte quell'istante in una data locale leggibile.

Qual è il timestamp Unix massimo?

Dipende dal tipo di archiviazione, non dall'epoch. Un intero con segno a 32 bit arriva al massimo a 2,147,483,647 (19 gennaio 2038), mentre un intero a 64 bit o un numero JavaScript raggiunge centinaia di milioni di anni. Vedi il problema dell'anno 2038 per i dettagli.