Tempo Unix in data — convertire qualsiasi epoch in una data leggibile

Il tempo Unix in data in una riga

Ecco l'intero compito in un esempio: il timestamp Unix 1700000000 diventa 2023-11-14T22:13:20Z — martedì 14 novembre 2023 alle 22:13:20 UTC. Un timestamp Unix conta i secondi dal 1° gennaio 1970 UTC; convertirlo significa decodificare quel conteggio come UTC e formattarlo nel fuso orario che ti serve. L'unica cosa che rompe le conversioni è l'unità: 10 cifre sono secondi, 13 millisecondi, 16 microsecondi. La tabella sottostante è l'istruzione pronta da copiare per ogni linguaggio e strumento di questa guida.

• Apri il convertitore di timestamp Unix
• Nella direzione opposta — data in timestamp Unix

Cosa significa convertire il tempo Unix in una data

Un timestamp Unix è il numero di secondi dal 1° gennaio 1970 UTC. Per convertirlo in una data lo si decodifica come UTC e poi lo si formatta in qualsiasi fuso orario. È tutto il problema in una frase — il resto di questa guida è solo la sintassi in ciascun linguaggio. Ogni linguaggio di programmazione moderno include una funzione integrata che prende un valore epoch Unix e restituisce un oggetto data; l'unica cosa a cui prestare attenzione è se il linguaggio si aspetta secondi (Python, PHP, Linux date), millisecondi (JavaScript Date) o microsecondi (PostgreSQL, BigQuery).

La regola di conversione rapida

Conta le cifre del tuo valore. Un numero di 10 cifre è in secondi Unix. Un numero di 13 cifre è in millisecondi Unix. Un numero di 16 cifre è in microsecondi Unix. L'epoch Unix è iniziata il 1° gennaio 1970 — quindi i valori a 10 cifre oggi (nel 2026) iniziano con 17 o 18; i millisecondi iniziano con 175 o 176 seguiti da 10 cifre; i microsecondi iniziano con 1758 o 1759. Rileva l'unità prima di passare il valore a una funzione di conversione, e il tuo output cadrà nel giorno giusto invece che nel 1970.

• 10 cifre → secondi Unix (intervallo dal 2001 al 2286)
• 13 cifre → millisecondi Unix (intervallo dal 2001 al 2286)
• 16 cifre → microsecondi Unix (intervallo dal 2001 al 2286)
• I numeri vicini a 10^9 (1.000.000.000) sono secondi precedenti al 2001 — sono ancora tempo Unix valido
• Gli interi negativi sono date precedenti al 1970 — la maggior parte dei linguaggi li gestisce; da verificare
• I numeri superiori a 2^31 nelle colonne INT raggiungono il limite dell'anno 2038 — vedi sotto

• Millisecondi vs secondi — la guida completa alle unità

Convertire il tempo Unix in una data in JavaScript

Il costruttore Date di JavaScript si aspetta millisecondi, quindi un valore in secondi Unix va prima moltiplicato per 1000. Il risultato è un oggetto Date; formattalo con toISOString() per ISO 8601 in UTC, o con Intl.DateTimeFormat per una stringa leggibile con fuso orario. Passa sempre un'opzione timeZone esplicita — senza, JavaScript usa il fuso orario locale dell'ambiente, che differisce tra i portatili di sviluppo e i server di produzione.

• new Date(1700000000 * 1000).toISOString() // '2023-11-14T22:13:20.000Z'
• new Date(1700000000 * 1000).toLocaleString('en-US', { timeZone: 'America/New_York' }) // tz-aware
• new Date(1700000000000).toISOString() // milliseconds — no × 1000 needed
• new Intl.DateTimeFormat('en-US', { timeZone: 'Asia/Tokyo', dateStyle: 'full', timeStyle: 'long' }).format(new Date(ms))
• Detect unit at runtime: const toDate = ts => new Date(ts < 1e11 ? ts * 1000 : ts)

• MDN — costruttore Date()
• Formattazione delle date corretta per fuso orario in JavaScript (guida correlata)

Convertire il tempo Unix in una data in Python

datetime.fromtimestamp(ts, tz=timezone.utc) è la conversione canonica in Python. L'argomento tz è obbligatorio per un risultato in UTC; senza, Python restituisce il timestamp nel fuso orario locale del sistema — una fonte frequente di bug di sfasamento del fuso sui server. utcfromtimestamp() è deprecato da Python 3.12 perché restituiva un datetime naive facile da usare male. Per i millisecondi, dividi per 1000; per i microsecondi, per 1.000.000 — Python accetta direttamente le frazioni di secondo.

• from datetime import datetime, timezone
• datetime.fromtimestamp(1700000000, tz=timezone.utc) # 2023-11-14 22:13:20+00:00
• datetime.fromtimestamp(1700000000.123, tz=timezone.utc) # fractional seconds work
• datetime.fromtimestamp(ms / 1000, tz=timezone.utc) # from milliseconds
• datetime.fromtimestamp(us / 1_000_000, tz=timezone.utc) # from microseconds
• Avoid: datetime.utcfromtimestamp(ts) — deprecated in 3.12; returns naive datetime

• Python — datetime.fromtimestamp

Convertire il tempo Unix in una data in PHP

gmdate(format, timestamp) in PHP restituisce una stringa di data in UTC per i secondi Unix dati; date(format, timestamp) restituisce lo stesso istante nel fuso orario locale del server (controllato da date_default_timezone_set o php.ini). La classe DateTime con DateTimeZone offre l'API moderna e immutabile e supporta qualsiasi nome di fuso IANA. PHP lavora in secondi per impostazione predefinita, quindi dividi prima per 1000 i valori in millisecondi.

• gmdate('c', 1700000000) // '2023-11-14T22:13:20+00:00' (UTC ISO 8601)
• date('Y-m-d H:i:s', 1700000000) // server-local — depends on date.timezone setting
• new DateTime('@1700000000') // immutable, UTC by default with the @ prefix
• (new DateTime('@1700000000'))->setTimezone(new DateTimeZone('Asia/Tokyo'))->format('c')
• DateTime::createFromFormat('U.u', '1700000000.123456') // sub-second precision

• PHP — riferimento gmdate()

Convertire il tempo Unix in una data in Java

L'API java.time di Java (Java 8+) converte i secondi Unix con Instant.ofEpochSecond(s), che restituisce un istante UTC — Instant è sempre in UTC, quindi non c'è alcuna sorpresa nascosta legata al fuso locale. Usa Instant.ofEpochMilli(ms) per input in millisecondi, allega un fuso con atZone(ZoneId.of(...)) per una resa a orologio da parete, e formatta con DateTimeFormatter. Il costruttore legacy java.util.Date si aspetta millisecondi, come JavaScript — moltiplica prima i secondi per 1000L.

• Instant.ofEpochSecond(1700000000) // 2023-11-14T22:13:20Z (UTC)
• Instant.ofEpochMilli(1700000000000L) // from milliseconds
• Instant.ofEpochSecond(1700000000).atZone(ZoneId.of("Asia/Tokyo")) // tz-aware
• DateTimeFormatter.ISO_INSTANT.format(Instant.ofEpochSecond(s)) // ISO 8601
• new java.util.Date(1700000000L * 1000) // legacy API — expects milliseconds

• Timestamp Unix in Java — riferimento completo

Convertire il tempo Unix in una data in C# (.NET)

In .NET, DateTimeOffset.FromUnixTimeSeconds(s) è la conversione moderna — restituisce un DateTimeOffset ancorato a UTC (+00:00). Usa FromUnixTimeMilliseconds(ms) per input in millisecondi. Leggi .UtcDateTime per un DateTime in UTC, oppure converti verso un fuso specifico con TimeZoneInfo.ConvertTime. Formatta con lo specificatore round-trip "o" per ISO 8601. I metodi Unix integrati (aggiunti in .NET 4.6) gestiscono il calcolo dell'epoch, quindi evita il vecchio schema DateTime.AddSeconds-dal-1970.

• DateTimeOffset.FromUnixTimeSeconds(1700000000) // 2023-11-14 22:13:20 +00:00
• DateTimeOffset.FromUnixTimeMilliseconds(1700000000000) // from milliseconds
• DateTimeOffset.FromUnixTimeSeconds(s).UtcDateTime // DateTime in UTC
• TimeZoneInfo.ConvertTime(dto, tzInfo) // tz-aware rendering
• DateTimeOffset.FromUnixTimeSeconds(s).ToString("o") // ISO 8601 round-trip

• Timestamp Unix in C# — riferimento completo

Convertire il tempo Unix in una data in Go

time.Unix(sec, nsec) in Go costruisce un Time a partire dai secondi Unix (più nanosecondi opzionali), ma restituisce il valore nel fuso orario locale — chiama .UTC() per ancorarlo. Go 1.17 ha aggiunto time.UnixMilli(ms) e time.UnixMicro(us), quindi non dividi più a mano. Formatta con la costante RFC3339 per ISO 8601, e usa .In(loc) con time.LoadLocation per un fuso specifico.

• time.Unix(1700000000, 0).UTC() // 2023-11-14 22:13:20 +0000 UTC
• time.UnixMilli(1700000000000).UTC() // from milliseconds (Go 1.17+)
• time.UnixMicro(1700000000000000).UTC() // from microseconds (Go 1.17+)
• time.Unix(1700000000, 0).Format(time.RFC3339) // ISO 8601 string
• time.Unix(s, 0).In(loc) // tz-aware; loc from time.LoadLocation

• Timestamp Unix in Go — riferimento completo

Convertire il tempo Unix in una data nella shell (Linux / macOS)

Su Linux, il comando GNU date usa -d @ts per convertire dai secondi Unix; su macOS, il comando BSD date usa -r ts per lo stesso compito. I flag differiscono a seconda dell'implementazione storica — il calcolo dell'epoch in sé è identico. Il flag -u forza un output in UTC indipendentemente dalla variabile d'ambiente TZ. Entrambe le implementazioni supportano formati di output arbitrari tramite l'argomento +%FORMAT; le stringhe di formato più utili sono riassunte sotto.

• GNU (Linux): date -u -d @1700000000 // 'Tue Nov 14 22:13:20 UTC 2023'
• GNU: date -u -d @1700000000 +'%Y-%m-%dT%H:%M:%SZ' // ISO 8601 UTC
• BSD (macOS): date -u -r 1700000000 // same result, different flag
• BSD: date -u -r 1700000000 +'%Y-%m-%dT%H:%M:%SZ'
• Both: omit -u to use TZ environment variable; export TZ=America/New_York to override
• Sub-second: date -u -d @1700000000.123 +'%Y-%m-%dT%H:%M:%S.%3NZ' (GNU only)

• man date(1) — riferimento del comando date di Linux

Convertire il tempo Unix in una data in SQL (Postgres, MySQL, SQLite, BigQuery)

Ogni grande dialetto SQL ha una funzione integrata per convertire i secondi Unix (o i millisecondi, o i microsecondi) in una colonna timestamp nativa. I nomi delle funzioni variano, ma l'unità che ciascuna si aspetta è documentata e coerente all'interno di un database. Usa la funzione dedicata invece di calcolare il risultato a mano con l'aritmetica delle date — le funzioni integrate gestiscono correttamente gli anni bisestili, la precisione sub-secondo e la conversione di fuso orario.

• PostgreSQL: TO_TIMESTAMP(1700000000) // returns TIMESTAMPTZ
• PostgreSQL: TO_TIMESTAMP(unix_us / 1000000.0) // for microsecond input
• MySQL: FROM_UNIXTIME(1700000000) // returns DATETIME in session timezone
• MySQL: CONVERT_TZ(FROM_UNIXTIME(ts), @@session.time_zone, 'UTC') // force UTC
• SQLite: datetime(1700000000, 'unixepoch') // returns TEXT 'YYYY-MM-DD HH:MM:SS'
• SQLite: datetime(ms / 1000, 'unixepoch') // from milliseconds
• BigQuery: TIMESTAMP_SECONDS(1700000000), TIMESTAMP_MILLIS(ms), TIMESTAMP_MICROS(us)
• ClickHouse: toDateTime(1700000000), fromUnixTimestamp(1700000000)

• PostgreSQL — funzioni di formattazione dei tipi di dato
• Come memorizzare i timestamp Unix in un database (guida correlata)

Convertire il tempo Unix in una data in Excel

Excel memorizza le date come numeri seriali — il numero di giorni dal 1° gennaio 1900. Convertire un timestamp Unix in una data Excel è solo conversione di unità: dividi i secondi Unix per 86.400 (secondi al giorno) e aggiungi la data del 1° gennaio 1970, poi formatta la cella come data. La formula =A1/86400 + DATE(1970,1,1) è la risposta canonica e funziona in tutte le versioni moderne di Excel. Per i millisecondi, dividi invece per 86.400.000. Dopo aver inserito la formula, seleziona la cella, apri Formato celle (Ctrl+1) e scegli un formato Data nella scheda Numero.

• Seconds: =A1/86400 + DATE(1970,1,1) // when A1 holds the Unix seconds value
• Milliseconds: =A1/86400000 + DATE(1970,1,1)
• Microseconds: =A1/86400000000 + DATE(1970,1,1)
• Format cell as Date after entering the formula (Ctrl+1 → Number → Date)
• Caveat: Excel's epoch is 1900-01-01, not 1970, hence the + DATE(1970,1,1) offset
• Reverse direction (date to Unix): =(A1 - DATE(1970,1,1)) * 86400

• Microsoft — funzione DATE

Convertire il tempo Unix in una data in Google Sheets

Google Sheets accetta la stessa formula canonica di Excel e fornisce anche una funzione EPOCHTODATE dedicata. La forma breve è =EPOCHTODATE(A1, 1), dove il secondo argomento è il codice di unità: 1 per i secondi, 2 per i millisecondi, 3 per i microsecondi. L'output è una data ancorata a UTC che Sheets rende secondo le impostazioni locali del foglio. Per i fogli condivisi tra team in fusi diversi, documenta nell'intestazione di colonna quale fuso le date dovrebbero rappresentare.

• =EPOCHTODATE(A1, 1) // seconds — shorthand
• =EPOCHTODATE(A1, 2) // milliseconds
• =EPOCHTODATE(A1, 3) // microseconds
• =A1/86400 + DATE(1970,1,1) // canonical formula — works in Sheets too
• Reverse direction: =(A1 - DATE(1970,1,1)) * 86400
• Time zone applied is the sheet's locale; check File → Settings → Time zone

Data UTC vs data locale — quale mostrare

Un timestamp Unix codifica un istante, non una resa a orologio da parete. Due visitatori in fusi diversi vedono lo stesso timestamp Unix come date d'orologio diverse. Il comportamento corretto dipende da ciò che la data rappresenta: i log di eventi e i record di audit dovrebbero essere mostrati in UTC per un confronto tra regioni; le date rivolte all'utente (scadenze, orari delle riunioni, avvisi di scadenza) dovrebbero essere mostrate nel fuso locale dell'utente. Scegline sempre uno e documentalo; non memorizzare mai una stringa già convertita in ora locale senza memorizzare anche il fuso da cui proviene.

• Log dei server → mostrare in UTC, etichettare esplicitamente la colonna o l'asse del grafico
• Scadenze rivolte all'utente → mostrare nel fuso dell'utente (rilevamento automatico tramite Intl.DateTimeFormat().resolvedOptions().timeZone)
• Pianificazioni ricorrenti ('ogni lunedì alle 9 Eastern') → memorizzare il fuso insieme alla regola, ricalcolare l'istante successivo a ogni esecuzione
• Risposte delle API → ISO 8601 con suffisso Z (UTC) è il default sicuro; lascia che sia il client a convertire
• Memorizzazione su database → sempre UTC; convertire solo nel livello di presentazione

• Database dei fusi orari IANA (le regole usate da ogni runtime)
• ISO 8601 — il formato di data da produrre in output

Casi limite: precisione sub-secondo, timestamp negativi e l'anno 2038

Tre casi limite fanno inciampare codice altrimenti corretto. I timestamp in microsecondi (16 cifre) richiedono una gestione esplicita dell'unità; trattarli come secondi dà una data 1.000.000× troppo lontana nel futuro. I timestamp Unix negativi rappresentano date precedenti al 1970 — la maggior parte dei linguaggi li gestisce, ma Excel, Google Sheets e alcune funzioni SQL li limitano al 1970 o restituiscono errori. Il problema dell'anno 2038 è l'overflow dell'intero con segno a 32 bit che si verifica il 19/01/2038 alle 03:14:07 UTC; i valori successivi richiedono memorizzazione BIGINT o time_t a 64 bit.

• Microsecondi (16 cifre) — dividere per 1.000.000 prima di passare alle funzioni in secondi del linguaggio
• Secondi negativi — date precedenti al 1970; JavaScript Date, Python datetime e PHP DateTime li gestiscono tutti
• Secondi negativi in Excel — producono #### o una data errata; usa la formula =A1/86400 + DATE(1970,1,1) solo per valori positivi
• Anno 2038 — INT e time_t con segno a 32 bit vanno in overflow a 2147483647 = 2038-01-19 03:14:07 UTC
• Oltre il 2038 — memorizzare come BIGINT (il 64 bit con segno copre 292 miliardi di anni da entrambi i lati dell'epoch)
• Prima del 1900 in Excel — l'applicazione non sa renderlo; converti in testo o usa una libreria a monte che supporti le date a.C.

• Il problema dell'anno 2038 (Y2K38) — guida completa

Bug frequenti nella conversione del tempo Unix in una data

Lo stesso bug compare ogni volta che qualcuno converte il tempo Unix in una data per la prima volta: il risultato cade nel 1970. La causa è quasi sempre un × 1000 dimenticato in JavaScript, o l'argomento tz mancante in Python, o una colonna numerica troncata automaticamente da Excel. L'articolo correlato sui bug ne cataloga tutti e 10 — ognuno compare in codice che converte il tempo Unix a un certo punto. Leggilo una volta e la maggior parte non arriverà mai in produzione.

• La data mostra 1970 — hai passato secondi dove erano attesi millisecondi (costruttore JS Date)
• La data è sfasata del tuo offset UTC locale — hai dimenticato di specificare tz=timezone.utc (Python) o l'opzione timeZone (JS)
• Excel mostra ##### o un errore #VALORE! — la cella non è formattata come Data, o il valore è negativo
• SQL FROM_UNIXTIME restituisce l'orologio da parete sbagliato — MySQL applica @@session.time_zone; forza UTC esplicitamente
• Server vs portatile producono date diverse — fusi di sistema diversi; passa sempre tz esplicitamente

• 10 bug frequenti dei timestamp Unix e come correggerli (correlato)