Convertitore timestamp Unix

Che cos’è un timestamp Unix?

Un timestamp Unix, detto anche tempo Unix, epoch time o tempo POSIX, è il numero di secondi trascorsi dal 1° gennaio 1970 alle 00:00:00 UTC. Quell’istante si chiama «epoch». Un secondo dopo il contatore era a 1, un giorno dopo a 86.400.

Lo stesso istante ha lo stesso timestamp in tutto il mondo. Fusi orari e ora legale entrano in gioco solo quando trasformi il numero in una data leggibile da una persona. Per questo server, database, log e API lo adorano: un solo intero, nessun fuso orario, facile da ordinare e da sottrarre.

Secondi o millisecondi?

La maggior parte dei sistemi conta in secondi: oggi è un numero di 10 cifre. JavaScript, Java e molte API contano in millisecondi: 13 cifre. Alcuni database e strumenti di tracciamento scendono ai microsecondi (16 cifre) o ai nanosecondi (19 cifre).

Il convertitore qui sopra guarda la lunghezza del numero e sceglie l’unità al posto tuo. Se la data cade nel 1970 o in un futuro lontanissimo, l’unità era probabilmente sbagliata: dividi o moltiplica per 1000.

Il problema dell’anno 2038

Molti sistemi vecchi salvano il timestamp in un intero a 32 bit con segno. Il valore più grande che può contenere è 2.147.483.647, cioè il 19 gennaio 2038 alle 03:14:07 UTC. Un secondo dopo il contatore va in overflow e passa a −2.147.483.648: quei sistemi leggono allora il 13 dicembre 1901 alle 20:45:52.

I sistemi moderni a 64 bit sono al sicuro per miliardi di anni. Il rischio sta nei dispositivi embedded, nei vecchi formati di file, nei database con colonne a 32 bit e nel codice che converte l’ora in un intero a 32 bit. Su Linux, le piattaforme a 32 bit hanno ricevuto il tempo a 64 bit con il kernel 5.6 nel 2020 e con la glibc 2.34 nel 2021, ma i programmi vanno ancora ricompilati per sfruttarlo. Un buon test: salva una data del 2040 e rileggila.

Il tempo Unix e i secondi intercalari

Il tempo Unix fa finta che ogni giorno duri esattamente 86.400 secondi. Il tempo UTC reale, invece, ha ricevuto 27 secondi intercalari dal 1972, l’ultimo il 31 dicembre 2016. Durante un secondo intercalare il tempo Unix di solito ripete un secondo, oppure allunga di poco i secondi intorno, una tecnica chiamata smearing usata da alcuni grandi fornitori cloud. Un timestamp Unix quindi non è un conteggio rigoroso dei secondi trascorsi: è un numero di giorni moltiplicato per 86.400, più i secondi del giorno in corso.

In pratica conta di rado, e conterà sempre meno. Nel novembre 2022 la Conferenza generale dei pesi e delle misure ha deciso di allargare entro il 2035 lo scarto ammesso tra l’UTC e la rotazione della Terra, il che di fatto mette fine ai secondi intercalari. L’IERS, il servizio internazionale che segue la rotazione terrestre, ha già annunciato che a fine dicembre 2026 non ci sarà alcun secondo intercalare.

Fusi orari e ora legale

Un timestamp indica un istante, non l’ora segnata da un orologio. Al timestamp 1.700.000.000 erano le 22:13 a Londra, le 23:13 a Roma e le 17:13 a New York: tre ore locali, un solo numero. Quando salvi delle date, conserva il timestamp (o una data ISO 8601 con «Z») e passa all’ora locale solo per mostrarla.

L’ora legale lo dimostra bene. Nella notte del ritorno all’ora solare, a fine ottobre, in Italia l’ora locale dalle 2:00 alle 3:00 si ripete due volte: un’ora locale da sola è quindi ambigua. I timestamp invece continuano a salire secondo dopo secondo, senza salti. Nella notte del passaggio all’ora legale, a fine marzo, un’ora locale sparisce, ma non manca nessun timestamp.

Timestamp o ISO 8601?

L’ISO 8601 è il gemello leggibile del timestamp: 2023-11-14T22:13:20Z indica lo stesso istante di 1.700.000.000. Il timestamp è compatto e facile da confrontare; la data ISO si legge bene in un log o in un file JSON. Entrambi sono senza ambiguità, purché la data ISO porti la «Z» o uno scarto come +01:00.

Come ottenere un timestamp Unix nel codice

// Ora Unix attuale in secondi (Date.now() è in millisecondi)
Math.floor(Date.now() / 1000)

// Da timestamp a data
new Date(1700000000 * 1000).toISOString()   // "2023-11-14T22:13:20.000Z"

// Da data a timestamp
Date.UTC(2026, 0, 1) / 1000                  // 1767225600

import time
from datetime import datetime, timezone

int(time.time())                                       # ora Unix attuale
datetime.fromtimestamp(1700000000, tz=timezone.utc)    # 2023-11-14 22:13:20+00:00
int(datetime(2026, 1, 1, tzinfo=timezone.utc).timestamp())   # 1767225600

time();                                   // ora Unix attuale
gmdate('Y-m-d H:i:s', 1700000000);        // "2023-11-14 22:13:20"
strtotime('2026-01-01 00:00:00 UTC');     // 1767225600

-- MySQL (FROM_UNIXTIME usa il fuso orario della sessione)
SELECT UNIX_TIMESTAMP();
SELECT FROM_UNIXTIME(1700000000);

-- PostgreSQL
SELECT EXTRACT(EPOCH FROM now())::bigint;
SELECT to_timestamp(1700000000);

-- SQLite
SELECT strftime('%s', 'now');
SELECT datetime(1700000000, 'unixepoch');

date +%s                              # ora Unix attuale
date -u -d @1700000000                # Linux (date GNU)
date -u -r 1700000000                 # macOS e BSD
date -u -d '2026-01-01 00:00' +%s     # 1767225600 (date GNU)

Gli errori più comuni

• L’ora locale per sbaglio. Creare una data da «2026-01-01 00:00» senza fuso usa l’ora locale del computer. Aggiungi «Z» o «UTC», oppure usa la scelta UTC qui sopra, quando intendi l’UTC.
• Secondi letti come millisecondi. Un numero di 10 cifre letto in millisecondi cade nel gennaio 1970. Un numero di 13 cifre letto in secondi cade tra decine di migliaia di anni.
• Timestamp negativi. Le date prima del 1970 sono numeri negativi: −86.400 corrisponde al 31 dicembre 1969. Quasi tutti gli strumenti moderni li gestiscono, alcuni vecchi no.

Per sapere che ora è in un’altra città in un dato istante, usa il convertitore di fusi orari. Per contare i giorni tra due date c’è il calcolatore di date, e per le durate in ore e minuti il calcolo ore e minuti.