Timestamp Unix Spiegati: Conversione e Insidie Comuni

Un timestamp Unix è uno dei concetti più semplici eppure più fraintesi nella programmazione. È il numero di secondi trascorsi dal 1 gennaio 1970, 00:00:00 UTC — un momento noto come l'epoch Unix. Nonostante la sua semplicità, i timestamp sono una fonte di bug legati ai fusi orari, alla precisione e all'overflow.

Cos'è l'Epoch Unix?

L'epoch Unix — 1 gennaio 1970, 00:00:00 UTC — è stato scelto come punto di partenza per il tempo Unix. Ogni timestamp è misurato rispetto a questo momento:

I timestamp negativi rappresentano date precedenti all'epoch. Ad esempio, -86400 corrisponde al 31 dicembre 1969.

Converti i timestamp istantaneamente con il nostro Convertitore di Timestamp.

Secondi vs. Millisecondi

Questa è la fonte di confusione più comune. Diversi sistemi usano diverse precisioni:

Regola pratica: Se il numero ha 13 cifre, è in millisecondi. Se ha 10 cifre, è in secondi.

// JavaScript restituisce millisecondi
const nowMs = Date.now();          // 1700000000000
const nowSec = Math.floor(nowMs / 1000);  // 1700000000

Gestione dei Fusi Orari

I timestamp Unix sono sempre in UTC. Non contengono informazioni sul fuso orario. Questa è in realtà una caratteristica — fornisce un punto di riferimento universale.

La confusione nasce quando si convertono i timestamp in date leggibili dall'uomo:

const ts = 1700000000;
const date = new Date(ts * 1000);

date.toUTCString();      // "Tue, 14 Nov 2023 22:13:20 GMT"
date.toLocaleString();    // Dipende dal fuso orario locale dell'utente
date.toISOString();       // "2023-11-14T22:13:20.000Z"

Best practice: Archivia e trasmetti i timestamp in UTC. Converti all'ora locale solo al livello di presentazione, il più vicino possibile all'utente.

Il Problema dell'Anno 2038

I sistemi Unix tradizionali archiviano i timestamp come interi con segno a 32 bit. Il valore massimo è 2.147.483.647, che corrisponde al 19 gennaio 2038, 03:14:07 UTC.

Dopo questo momento, i timestamp a 32 bit vanno in overflow verso valori negativi, tornando al 13 dicembre 1901. Questo è analogo al bug Y2K.

Stato attuale:

• La maggior parte dei sistemi moderni usa timestamp a 64 bit (validi fino all'anno 292 miliardi)
• Il kernel Linux è pulito per timestamp a 64 bit dalla versione 5.6 (2020)
• I sistemi embedded e i database legacy rimangono a rischio
• Se stai costruendo software che gestisce date oltre il 2038, verifica l'archiviazione dei tuoi timestamp

Conversione in Diversi Linguaggi

JavaScript

// Timestamp corrente (secondi)
const now = Math.floor(Date.now() / 1000);

// Timestamp a Date
const date = new Date(1700000000 * 1000);

// Date a timestamp
const ts = Math.floor(new Date('2023-11-14').getTime() / 1000);

Python

import time, datetime

# Timestamp corrente
now = int(time.time())

# Timestamp a datetime
dt = datetime.datetime.fromtimestamp(1700000000, tz=datetime.timezone.utc)

# Datetime a timestamp
ts = int(dt.timestamp())

SQL (PostgreSQL)

-- Timestamp corrente
SELECT EXTRACT(EPOCH FROM NOW());

-- Timestamp a data
SELECT TO_TIMESTAMP(1700000000);

-- Data a timestamp
SELECT EXTRACT(EPOCH FROM '2023-11-14'::timestamp);

Insidie Comuni

1. Mescolare Secondi e Millisecondi

Se una data mostra gennaio 1970, probabilmente hai passato secondi dove erano attesi millisecondi (o viceversa). Controlla sempre quale precisione si aspetta l'API.

2. Ignorare i Fusi Orari nelle Stringhe di Data

Analizzare "2023-11-14" senza fuso orario crea la data nel fuso orario locale, che varia in base alla posizione del server. Includi sempre il fuso orario: "2023-11-14T00:00:00Z".

3. Precisione dei Numeri in Virgola Mobile

Quando archivi i timestamp come numeri in virgola mobile, potresti perdere precisione oltre i millisecondi. Per la precisione a microsecondi o nanosecondi, usa interi con il moltiplicatore appropriato.

4. Secondi Intercalari

I timestamp Unix non tengono conto dei secondi intercalari. Un giorno Unix è sempre esattamente 86.400 secondi, anche se i giorni UTC effettivi occasionalmente hanno 86.401 secondi. Per la maggior parte delle applicazioni, questo è irrilevante. Per applicazioni scientifiche o satellitari, usa il TAI (Tempo Atomico Internazionale).

ISO 8601: L'Alternativa Leggibile dall'Uomo

Mentre i timestamp sono ottimi per il calcolo, ISO 8601 è lo standard per la rappresentazione leggibile delle date:

2023-11-14T22:13:20Z          # UTC
2023-11-14T17:13:20-05:00     # Eastern Time
2023-11-14                     # Solo data

La maggior parte delle API dovrebbe accettare e restituire stringhe ISO 8601. Usa i timestamp internamente per calcoli e archiviazione.

FAQ

Perché il tempo Unix inizia il 1 gennaio 1970?

La data è stata scelta arbitrariamente quando Unix veniva sviluppato ai Bell Labs nei primi anni '70. Serviva una data abbastanza recente per evitare di sprecare bit su date del passato remoto. Poiché gli interi a 32 bit possono memorizzare circa 68 anni in ogni direzione, partire dal 1970 copriva le date dal 1901 al 2038.

Devo archiviare le date come timestamp o stringhe formattate nel mio database?

Archivia le date come timestamp (interi o tipi datetime nativi) per un ordinamento, confronto e aritmetica efficienti. Le stringhe formattate sono più difficili da interrogare e ordinare correttamente. La maggior parte dei database ha tipi datetime nativi che gestiscono bene questo aspetto. Riserva la formattazione delle stringhe per la visualizzazione e le risposte API.

Risorse Correlate

• Convertitore di Timestamp — Converti tra timestamp Unix e date leggibili
• Best Practice per la Formattazione JSON — Gestire le date nelle risposte JSON
• Guida UUID — Un altro formato di identificatore comune con varianti basate sul tempo