Encoders & Utilities

Unix Timestamp e calcolatore date

Converte epoch Unix in date leggibili, calcola aritmetica e differenze tra date.

Informazioni su questo strumento

Unix Timestamp & Date Calculator converte tra epoch Unix interi e date in formato ISO 8601 / localizzato in entrambe le direzioni. Si incolla un numero e lo strumento indica se si sono forniti secondi (10 cifre), millisecondi (13 cifre), microsecondi (16) o nanosecondi (19) — e rende la data corrispondente in UTC, nel proprio fuso orario locale e in qualsiasi fuso orario selezionato dalla lista IANA. Nell'altra direzione, si incolla una stringa data in qualsiasi formato comune e si ottiene l'epoch.

Una seconda modalità gestisce l'aritmetica delle date: aggiungere o sottrarre giorni, ore, minuti da una data base; calcolare la differenza tra due date come giorni/ore/minuti/secondi (o "3 anni, 2 mesi, 14 giorni" se si preferisce in unità di calendario). Tutta la matematica viene eseguita nel browser usando Temporal dove disponibile e una libreria di fallback altrimenti — nessuna sorpresa di fuso orario dovuta a transizioni DST, leap second (ignorati, come nello stesso Unix time) o il rollover 2038 (gestiamo nativamente timestamp a 64 bit).

Quando usare questo strumento

  • Debug dei log. Una voce di log con epoch 1747459200 — incollala, vedi "17 maggio 2026 04:00 UTC", fatto.
  • Verifiche di sanità sulle date nel database. Verificare che un valore archiviato come BIGINT ms decodifichi effettivamente nella data umana attesa.
  • Aritmetica SLA / cron. "Cosa fanno 72 ore da ora in fuso Tokyo?" — risposto in due clic.
  • Scadenza dei token. Il claim exp di un JWT è un epoch — incollalo qui per la risposta leggibile.

Sul problema del 2038

I timestamp Unix con segno a 32 bit traboccano alle 03:14:07 UTC del 19 gennaio 2038 (il bug "Y2038"). La soluzione è utilizzare timestamp a 64 bit, che la maggior parte dei linguaggi e dei database moderni usa di default oggi. Il nostro calcolatore usa 64 bit internamente — valori oltre il 2038, e ben oltre l'anno 100.000, vengono calcolati correttamente. I sistemi legacy su hardware embedded sono la superficie di esposizione residua.

Domande frequenti

Perché il mio "timestamp" è lungo 13 cifre?

È in millisecondi, non secondi. JavaScript, Java e molte API più recenti usano di default la risoluzione al millisecondo; lo Unix classico è in secondi. 10 cifre = secondi (era attuale fino al 2286), 13 cifre = millisecondi, 16 cifre = microsecondi, 19 cifre = nanosecondi. Il nostro parser rileva la precisione dal conteggio delle cifre e converte di conseguenza.

Lo strumento gestisce correttamente i fusi orari?

Sì — ogni conversione mostra UTC accanto al fuso orario selezionato (di default il fuso locale del browser). Le transizioni di ora legale vengono rispettate per i fusi IANA (ad esempio "Europe/Berlin" gestisce automaticamente i passaggi CET/CEST). Si presti attenzione alle stringhe a offset fisso ("+02:00") — sembrano uguali in un giorno normale ma ignorano la DST.

Perché la mia aritmetica sugli anni è diversa da una semplice divisione?

Perché le unità di calendario non sono uniformi. Un "anno" è in media 365,2425 giorni; alcuni sono 365, altri 366. Sottrarre due date in "anni e mesi" richiede un vero camminare sul calendario, non solo dividere secondi. Il nostro strumento fa il cammino; una semplice approssimazione seconds / (365 * 86400) deriva di circa 6 ore per anno.

Cos'è il problema Y2038?

Un timestamp Unix con segno a 32 bit trabocca alle 03:14:07 UTC del 19 gennaio 2038. I sistemi che usano ancora time a 32 bit ribalteranno a un valore negativo (interpretato come 13 dicembre 1901). Linux, Windows e macOS moderni usano tutti timestamp a 64 bit, sufficienti fino all'anno 292.277.026.596. I sistemi embedded legacy sono il rischio persistente.