Guida completa al timestamp Unix: conversione secondi/millisecondi/microsecondi e best practice sui fusi orari

I timestamp Unix rappresentano il tempo come “la quantità trascorsa dall’epoca Unix (1 gennaio 1970, 00:00:00 UTC)”. Oltre il 95% dei web server e il 90% dei sistemi di database a livello globale usano internamente questa rappresentazione. Questa guida copre le differenze di precisione, le implementazioni nei linguaggi di programmazione, la gestione dei fusi orari e considerazioni sull’ora legale.

Origini e definizione del timestamp Unix

L’epoch Unix è iniziata il 1 gennaio 1970, 00:00:00 UTC. Il timestamp Unix 0 corrisponde a questo momento, mentre 1262304000 rappresenta 2010-01-01 00:00:00 UTC. Il sistema ignora di default gli effetti dei leap second.

Originariamente memorizzato come intero a 32 bit con segno, questo ha creato il Problema dell’Anno 2038: il valore massimo va in overflow il 19 gennaio 2038, 03:14:07 UTC. I sistemi moderni usano interi a 64 bit, estendendo significativamente gli intervalli di tempo rappresentabili.

Differenze di precisione temporale

Unità	Conteggio per secondo	Cifre	Applicazioni tipiche
Secondi (s)	1	10	Sistemi Unix/Linux tradizionali
Millisecondi (ms)	1.000	13	JavaScript, Java, logging
Microsecondi (μs)	1.000.000	16	Distributed tracing, database
Nanosecondi (ns)	1.000.000.000	19	Linguaggio Go, analisi prestazionale

Regola pratica: i timestamp a 10 cifre rappresentano generalmente secondi, 13 cifre rappresentano millisecondi, 16 cifre rappresentano microsecondi e 19 cifre rappresentano nanosecondi.

Timestamp JavaScript

JavaScript usa nativamente i millisecondi. Il costruttore Date() assume che i numeri di input siano millisecondi: per timestamp a livello di secondo, moltiplica per 1000.

// Ottieni il timestamp Unix corrente (in millisecondi)
const timestampMs = Date.now();
console.log(timestampMs);  // Output esempio: 1692268800123

// Per timestamp a livello di secondo, dividi i millisecondi per 1000 e arrotonda per difetto
const timestampSec = Math.floor(Date.now() / 1000);
console.log(timestampSec); // Output esempio: 1692268800

// Converti il timestamp Unix di nuovo in oggetto Date
let ts = 1692268800;
let date = new Date(ts * 1000);
console.log(date.toISOString()); // "2023-08-17T16:00:00.000Z"

Timestamp Python

time.time() di Python restituisce timestamp Unix a livello di secondo come valori in virgola mobile:

import time
from datetime import datetime, timezone

# Ottieni il timestamp Unix corrente (secondi, float)
now_sec = time.time()
print(now_sec)  # Output esempio: 1692268800.123456

# Ottieni i millisecondi (intero)
now_millis = int(time.time() * 1000)
print(now_millis)  # Esempio: 1692268800123

# Ottieni i nanosecondi (Python 3.7+)
now_nanos = time.time_ns()
print(now_nanos)  # Esempio: 1692268800123456789

# Converti in datetime
ts = 1692268800
dt_local = datetime.fromtimestamp(ts)
dt_utc = datetime.fromtimestamp(ts, timezone.utc)
print(dt_local.strftime("%Y-%m-%d %H:%M:%S"))  # Ora locale
print(dt_utc.strftime("%Y-%m-%d %H:%M:%S"))    # Ora UTC

Timestamp del linguaggio Go

La libreria time di Go fornisce più livelli di precisione:

package main

import (
    "fmt"
    "time"
)

func main() {
    // Ottieni il timestamp Unix corrente
    sec := time.Now().Unix()        // Secondi
    msec := time.Now().UnixMilli()  // Millisecondi (Go 1.17+)
    nsec := time.Now().UnixNano()   // Nanosecondi

    fmt.Println(sec)   // Esempio: 1692268800
    fmt.Println(msec)  // Esempio: 1692268800123
    fmt.Println(nsec)  // Esempio: 1692268800123456789

    // Converti il timestamp in oggetto Time
    t := time.Unix(sec, 0)
    fmt.Println(t.UTC())
    fmt.Println(t)
}

Errori comuni e best practice

Esempio di errore: unità poco chiare

// ✗ Sbagliato: unità del timestamp poco chiara
const timestamp = 1692268800;
const date = new Date(timestamp); // Errore: trattato come millisecondi, mostra 1970

// ✓ Corretto: indica chiaramente le unità
const timestampSec = 1692268800;
const timestampMs = 1692268800000;
const dateFromSec = new Date(timestampSec * 1000);

Best practice per la denominazione dei campi

log_entry = {
    "timestamp_ms": 1692268800123,           # Livello millisecondo
    "timestamp_iso": "2023-08-17T16:00:00Z", # ISO 8601 UTC
    "event_type": "user_login",
    "user_id": 12345
}

Insidie nella gestione dei fusi orari

Ci sono quattro insidie principali quando lavori con i fusi orari:

Confondere ora locale e ora UTC — i timestamp Unix sono sempre basati su UTC; converti in locale solo al momento della visualizzazione
Non salvare le informazioni di fuso orario — crea ambiguità; memorizza sempre UTC o includi l’offset
Inconsistenze di fuso orario tra sistemi — tutti i sistemi dovrebbero usare lo stesso riferimento di fuso orario (raccomanda UTC)
Calcolare manualmente gli offset di ora legale — affidati a librerie integrate, non scrivere a mano

L’approccio raccomandato: “Memorizzazione standardizzata, visualizzazione localizzata.” Usa UTC o timestamp Unix nelle fasi di memorizzazione e trasmissione per garantire la consistenza; formatta secondo il fuso orario dell’utente quando visualizzi.

Problemi di ora legale (DST)

L’ora legale crea due periodi problematici:

Tempo saltato: quando inizia l’ora legale, gli orologi saltano in avanti. Ad esempio, le 02:00 saltano direttamente alle 03:00, rendendo le 02:30 inesistenti.
Tempo ripetuto: quando finisce l’ora legale, le 01:00–01:59 appaiono due volte, creando ambiguità.

I timestamp Unix stessi rimangono continui e non influenzati dall’ora legale, ma le conversioni in ora locale richiedono una gestione attenta.

Best practice per logging, database e API

Sistemi di logging

Unifica il fuso orario UTC + formato ISO 8601; includi timestamp in millisecondi o precisione al microsecondo quando necessario.

Database

Preferisci tipi calendario nativi con fuso orario; usa BIGINT per timestamp numerici con indicazione chiara dell’unità nei nomi dei campi (es. *_epoch_ms).

API

Specifica chiaramente formati e unità. Le interfacce esterne dovrebbero usare ISO 8601 (leggibile, include il fuso orario); i sistemi interni possono usare timestamp numerici con unità documentate.

Scenari di errore comuni

Errore di parsing a 13 cifre: timestamp in millisecondi forniti a funzioni che si aspettano secondi causano overflow. Determina prima le unità dal conteggio delle cifre.
Mismatch di formato: date non valide, fusi orari mancanti o punti di cambio dell’ora legale causano errori di parsing.
Offset di fuso orario: deviazioni di ore intere (±8h) tipicamente indicano problemi di unificazione. Raccomanda usare UTC internamente.
Overflow numerico: i sistemi a 32 bit affrontano i limiti del 2038; dai priorità a interi a 64 bit.

Domande frequenti

Perché 1 gennaio 1970?

Lo sviluppo del sistema operativo Unix è iniziato nel 1970, ed era un anno tondo della decade — facile da ricordare e calcolare. Gli interi a 32 bit potevano rappresentare date dal 1970 al 2038, il che era sufficiente all’epoca.

Come distinguere secondi e millisecondi?

Tre metodi: controlla il conteggio delle cifre (10 cifre = secondi, 13 = millisecondi, 16 = microsecondi, 19 = nanosecondi), calcola la verifica analizzando e controllando la ragionevolezza, oppure usa strumenti di conversione online.

Il problema del 2038 conta ancora?

I sistemi moderni che usano interi a 64 bit hanno largamente risolto questo problema. I principali linguaggi di programmazione supportano già timestamp a 64 bit. I sistemi legacy a 32 bit e i dispositivi embedded possono ancora richiedere attenzione.

Perché l’ora legale causa problemi?

La discontinuità temporale dalle ore saltate e la ripetizione temporale dalle ore ripetute creano ambiguità di parsing. Sistemi diversi gestiscono i tempi ambigui con strategie diverse. Soluzione: usa UTC internamente, converti in ora locale solo al momento della visualizzazione.

Perché i timestamp di JavaScript e Python differiscono?

Date.now() di JavaScript restituisce millisecondi (13 cifre); time.time() di Python restituisce secondi (virgola mobile con precisione al microsecondo). La conversione richiede divisione/moltiplicazione per 1000.

Tendenze recenti e prospettive future

Maggiore precisione: trading finanziario, IoT e sistemi in tempo reale richiedono precisione al nanosecondo
Sincronizzazione distribuita: i protocolli NTP e PTP migliorano la precisione
Timestamp blockchain: le criptovalute richiedono timestamp resistenti alla manomissione e ad alta precisione
Ottimizzazione delle prestazioni: istruzioni SIMD, cache di memoria ed elaborazione parallela accelerano le conversioni

Provalo

Converti istantaneamente i timestamp Unix con il nostro Convertitore Timestamp Unix — rileva automaticamente secondi, millisecondi e microsecondi. 100% nel tuo browser.

Lavori con PostgreSQL? Leggi Cosa Vive Esattamente Dentro una Colonna timestamp di PostgreSQL? per le insidie sui fusi orari specifiche di Postgres.

Riepilogo

Questa guida completa copre gli elementi essenziali del timestamp Unix — dalle origini dell’epoch e dalle conversioni multi-precisione alle implementazioni cross-language, alla gestione dei fusi orari, alle insidie dell’ora legale e alle best practice ingegneristiche in logging, database e progettazione di API. Il punto chiave: memorizza in UTC, visualizza in ora locale ed esplicita sempre le unità del timestamp.

I timestamp sono solo un pezzo del toolkit dello sviluppatore. Esplora altri strumenti essenziali per sviluppatori per codifica, hashing e conversione dei dati.

Guida online ai timestamp Unix: precisione, fuso e ora legale