Unix timestamp

Un Unix timestamp (o tempo POSIX, o secondi-dall’epoca) è il numero di secondi trascorsi dal 1970-01-01 00:00:00 UTC, ignorando i leap second. Al 2026-05-16 il Unix timestamp è di circa 1.779.000.000.

Perché questo formato domina il calcolo:

• È un singolo intero. Nessun fuso orario, calendario, locale o ambiguità DST incorporata.
• L’aritmetica del tempo è banale — sottrai due timestamp per ottenere una durata in secondi.
• Ordinabile come numeri. Gli indici dei database e le query di serie temporali non necessitano di comparatori sofisticati.
• Compatto nell’archiviazione e sul cavo.

Tre varianti che incontrerai:

• Secondi. L’originale. 1700000000 = 14 Nov 2023 22:13:20 UTC.
• Millisecondi. Date.now() di JavaScript restituisce questo. Moltiplica il valore in secondi per 1000.
• Microsecondi / nanosecondi. Telemetria ad alta risoluzione, tracce distribuite. Il timestamptz di Postgres memorizza microsecondi.

Due problemi ben noti:

• Anno 2038 (Y2K38). Un intero con segno a 32 bit in secondi va in overflow il 2038-01-19 alle 03:14:07 UTC. I sistemi moderni usano 64 bit (validi per ~292 miliardi di anni); i sistemi embedded legacy potrebbero non farlo.
• Leap second. UTC inserisce occasionali leap second per rimanere sincronizzato con la rotazione della Terra. Il tempo Unix li ignora — il timestamp nell’istante del leap second è ambiguo. La maggior parte dei sistemi di produzione usa uno smear (Google, AWS) che distribuisce il leap second nel corso di ore.

Converti i Unix timestamp in date leggibili (e viceversa) inserendoli in una libreria di date. La conversione in un orario a parete richiede sempre una scelta di fuso orario — lo stesso istante è “le 3pm a New York” e “mezzanotte a Tokyo” a seconda della zona in cui lo visualizzi. Vedi il nostro convertitore di fuso orario.

Come i sistemi operativi stanno migrando da time_t a 32 bit: Linux ha standardizzato time_t a 64 bit come ABI del kernel nel 2020 (kernel 5.6+) e glibc 2.32 (2020) lo ha esposto allo spazio utente. NetBSD ha fatto il passaggio nel 2012, OpenBSD nel 2014. FreeBSD ha seguito nel 2024. Le superfici rimanenti in ritardo sono i sistemi embedded che eseguono kernel più vecchi bloccati, certi protocolli on-chain che hanno codificato timestamp a 32 bit nel loro formato wire (l’header del blocco Bitcoin include un Unix timestamp a 32 bit, problematico intorno al 2106 quando si verificherebbe un overflow senza segno), e i formati di file legacy (gli archivi ZIP usano timestamp DOS a 32 bit con un’epoca del 1980; tar usa Unix timestamp a 32 bit). Il lavoro difficile è trovare e correggere queste situazioni; il lato del kernel è in gran parte risolto. Riferimento: POSIX.1-2017 §4.16 — Seconds Since the Epoch.

Esempio pratico

Converti 1700000000 in una data UTC leggibile. Dividi e calcola il modulo dai secondi: 1.700.000.000 / 86400 = 19.675,93 giorni dal 1970-01-01. Il giorno 19.675 è il 2023-11-14 (aritmetica del calendario). La frazione 0.93 di un giorno × 86.400 = 80.000 secondi = 22:13:20. Quindi 1700000000 = 2023-11-14T22:13:20Z. Verifica in JavaScript: new Date(1700000000 * 1000).toISOString() → "2023-11-14T22:13:20.000Z". Per visualizzare a Tokyo (UTC+9): aggiungi 9 ore = 2023-11-15T07:13:20+09:00. Lo stesso istante, orologio a parete diverso. Il bug classico: memorizzare new Date().getTime() (millisecondi) in una colonna che il resto del codebase tratta come secondi — ogni timestamp finisce per essere letto come l’anno 55.000+ quando visualizzato.

Quando e perché è importante

Ogni volta che due sistemi si scambiano dati temporali — frontend a backend, database a pipeline ETL, microservizio a microservizio — i Unix timestamp sono l’unica rappresentazione che non porta ambiguità di fuso orario, locale, calendario o DST. Memorizza i timestamp come Unix secondi o millisecondi in una colonna a 64 bit, formatta in ISO-8601 con fuso orario esplicito solo al margine per la visualizzazione umana. L’abitudine difensiva: in ogni colonna o campo API che porta il tempo, codifica l’unità (created_at_ms, expires_at_unix_seconds) in modo che un revisore del codice non possa confondere l’ordine di grandezza. Il rischio Y2038 è piccolo per i nuovi sistemi ma reale per qualsiasi timestamp a 32 bit nei formati wire del protocollo e nei sensori embedded — verificali ora che ci sono 12 anni di margine, non nel 2037 quando le patch saranno urgenti. Riferimento: RFC 3339 — Date and Time on the Internet.