Come convertire tra formati orari

· 9 min di lettura

I formati orari variano tra sistemi, API e paesi. Timestamp Unix nelle risposte API, ISO 8601 in database, orologi 12 h negli Stati Uniti, 24 h in Europa, la conversione è una necessità costante per gli sviluppatori e per chiunque lavori con dati internazionali.

Formati orari comuni

Formato Esempio Usato da
Timestamp Unix (secondi) 1712502600 API, database, token JWT
Timestamp Unix (ms) 1712502600000 JavaScript, Java
ISO 8601 2026-04-07T14:30:00Z API JSON, database, log
RFC 2822 Mon, 07 Apr 2026 14:30:00 +0000 Intestazioni e-mail, HTTP
24 h 14:30 Europa, militare, aviazione
12 h 2:30 PM Stati Uniti, uso comune

Promemoria di conversione rapida

12 h verso 24 h

12 h 24 h
12:00 AM (mezzanotte) 00:00
1:00 AM 01:00
12:00 PM (mezzogiorno) 12:00
1:00 PM 13:00
6:00 PM 18:00
11:59 PM 23:59

Timestamp verso date

Usa il convertitore epoch per tradurre istantaneamente un timestamp Unix in data leggibile e viceversa. Il convertitore gestisce automaticamente i formati in secondi e in millisecondi.

Consigli

Domande frequenti

Cos'è il formato ISO 8601?

ISO 8601 è lo standard internazionale per rappresentare date e orari. Assomiglia a 2026-04-07T14:30:00Z, dove T separa la data e l'ora, e Z indica UTC. È senza ambiguità qualunque sia la locale.

Perché le API usano timestamp Unix invece di date leggibili?

I timestamp Unix sono un singolo numero, facile da memorizzare, ordinare e confrontare. Sono neutri rispetto al fuso orario (sempre UTC) e occupano meno spazio di una stringa di data formattata. Il compromesso: non sono leggibili per un umano.

Cosa significa la Z alla fine di un timestamp?

La Z significa «Zulu time», un altro nome per UTC (Coordinated Universal Time). Un timestamp che finisce con Z è in UTC, non in ora locale.

Come convertire un'ora 24 h in 12 h?

Per le ore 1-12, l'ora resta la stessa (aggiungi AM per 0-11, PM per 12). Per 13-23, sottrai 12 e aggiungi PM. 00:00 diventa 12:00 AM (mezzanotte). 12:00 diventa 12:00 PM (mezzogiorno).

What is the Year 2038 problem?

32-bit signed Unix timestamps overflow on 19 January 2038 at 03:14:07 UTC, after which they wrap around to negative values that look like dates in 1901. Most modern systems use 64-bit timestamps and are unaffected, but legacy embedded devices, old databases, and 32-bit time_t in some C code still need to be audited.

How are leap seconds handled in Unix time?

Unix time pretends leap seconds do not exist. The clock simply repeats or stretches the affected second, so a Unix timestamp is not a strict count of elapsed SI seconds. For most applications this is fine, but precision-timing code (astronomy, GPS, high-frequency trading) needs TAI or UTC with explicit leap-second handling.