Cos'è Unix Epoch Time? Una guida per sviluppatori ai timestamp

Se hai mai interrogato un database o lavorato con un'API moderna, probabilmente hai visto le date restituite non come "12 ottobre 2026", ma come un'enorme e intimidatoria stringa di numeri come 1791800000. Questo è un Unix Timestamp ed è la spina dorsale universale del cronometraggio nell'informatica.

Gestire date e orari nella programmazione è notoriamente difficile. I fusi orari cambiano, l’ora legale inizia e finisce in modo imprevedibile e gli anni bisestili introducono giorni extra. Per risolvere questa realtà caotica, gli ingegneri che hanno costruito il sistema operativo Unix hanno deciso di inventare una propria linea temporale assoluta.

L'origine: 1 gennaio 1970

Un timestamp Unix è semplicemente il numero di secondi trascorsi dal 1 gennaio 1970 alle 00:00:00 UTC. Questo esatto momento storico è noto come "Unix Epoch".

Perché 1970? Perché all’inizio degli anni ’70 lo stoccaggio era incredibilmente costoso. La memorizzazione di una data come stringa leggibile dall'uomo come "1970-01-01 00:00:00" occupa quasi 20 byte di memoria. Memorizzarlo come un singolo numero intero a 32 bit ha richiesto solo 4 byte. Creando il punto di partenza vicino al momento in cui fu inventato Unix, massimizzarono la quantità di tempo futuro che potevano archiviare all'interno di quei 4 byte.

Perché gli sviluppatori amano i timestamp Unix

Il motivo principale per cui l'ora Unix è universalmente adottata in API, database e microservizi è che non ha fuso orario. Rappresenta un singolo momento assoluto nel tempo a livello globale.

Se salvi un evento in un database utilizzando l'ora del server locale ("15:00 EST") e successivamente trasferisci il tuo server a Londra, tutti i tuoi calcoli si interrompono. Ma se un evento si verifica al timestamp 1700000000, quel numero è identico indipendentemente dal fatto che l'utente che lo interroga si trovi a Tokyo, New York o Parigi. L'applicazione frontend prende semplicemente quel numero intero e lo converte matematicamente nel fuso orario locale dell'utente sullo schermo.

Secondi vs millisecondi (la regola delle 10 vs 13 cifre)

Uno dei bug più comuni nello sviluppo web è passare un timestamp a una funzione e ottenere una data nell'anno 1970 o nell'anno 52.000. Ciò accade a causa di un errore tra secondi e millisecondi.

• Ora Unix standard (secondi): un numero di 10 cifre (ad esempio, 1700000000). Questo è lo standard in Linux, PHP e nella maggior parte dei database backend come MySQL.
• Tempo JavaScript (millisecondi): un numero di 13 cifre (ad esempio, 1700000000000). La funzione Date.now() di JavaScript include i millisecondi per una maggiore precisione.

Se inserisci un timestamp di backend di 10 cifre in JavaScript senza moltiplicarlo per 1000, JavaScript presuppone che tu stia parlando dei primi giorni di gennaio 1970.

// Correctly handling a Unix timestamp in JavaScript
const backendTimestamp = 1700000000;
const dateObject = new Date(backendTimestamp * 1000);

console.log(dateObject.toLocaleDateString()); // Converts to local user timezone

Il problema dell’anno 2038 (Y2K38)

Il tempo di Unix ha una scadenza imminente. Poiché è stato originariamente memorizzato come intero con segno a 32 bit, il numero massimo che può contenere è 2.147.483.647.

Il 19 gennaio 2038, alle 03:14:07 UTC, l'orologio Unix raggiungerà quel numero massimo. Un secondo dopo, il numero intero traboccherà, trasformandosi in un numero negativo. I sistemi legacy che non sono stati aggiornati all'architettura a 64 bit crederanno improvvisamente che l'anno sia il 1901, causando guasti catastrofici nel software in tutto il mondo.

Fortunatamente, quasi tutto l’hardware, i database e i linguaggi di programmazione moderni (come i kernel Linux a 64 bit e il moderno Node.js) sono già passati al tempo a 64 bit, spostando il prossimo overflow di miliardi di anni nel futuro.

Domande frequenti (FAQ)