FAQ sui timestamp Unix
Risposte rapide alle domande più comuni sui timestamp Unix — unità, gestione dei fusi, il problema dell'anno 2038, conversioni specifiche per linguaggio e altro.
Domande frequenti
Domande comuni su timestamp Unix, tempo epoch, fusi orari e su come memorizzare correttamente il tempo — organizzate per argomento. Usa le risposte come riferimento rapido; guide più approfondite sono collegate in fondo alla pagina.
Dove andare dopo
FAQ
- Che cos'è un timestamp Unix?
- Un timestamp Unix è il numero di secondi trascorsi dall'epoch Unix — il 1° gennaio 1970 alle 00:00:00 UTC. È un intero neutrale rispetto al linguaggio e indipendente dal fuso orario che identifica in modo univoco qualsiasi istante.
- Che cos'è l'epoch Unix?
- L'epoch Unix è il 1° gennaio 1970 alle 00:00:00 UTC. Tutti i timestamp Unix si misurano in avanti — o all'indietro per i valori negativi — da questo punto di riferimento fisso. La scelta del 1970 fu pratica: era un anno recente e tondo quando Unix veniva progettato ai Bell Labs.
- Qual è la differenza tra un timestamp a 10 cifre e uno a 13 cifre?
- Un timestamp a 10 cifre (es. 1700000000) rappresenta secondi dall'epoch. Uno a 13 cifre (es. 1700000000000) rappresenta millisecondi. Il Date.now() di JavaScript restituisce millisecondi; la maggior parte delle chiamate di sistema Unix e linguaggi come Python, Go e PHP restituiscono secondi per impostazione predefinita.
- Perché JavaScript usa i millisecondi invece dei secondi?
- L'API Date di JavaScript fu progettata per corrispondere alla risoluzione dei timer di sistema disponibili nel 1995. Usare i millisecondi evita la perdita di precisione per durate inferiori al secondo. Quando lavori con timestamp Unix in secondi generati dal server, moltiplica per 1000 prima di passarli a new Date().
- Come converto un timestamp Unix in una data leggibile in JavaScript?
- Per un timestamp in secondi: new Date(1700000000 * 1000).toISOString(). Per un timestamp in millisecondi: new Date(1700000000000).toISOString(). Entrambi producono stringhe ISO 8601 come '2023-11-15T06:13:20.000Z'. Usa toLocaleString() con un'opzione timeZone per una visualizzazione localizzata.
- I timestamp Unix tengono conto del fuso orario?
- No. Un timestamp Unix rappresenta sempre un singolo istante in UTC. Le informazioni sul fuso vengono applicate solo quando si formatta il timestamp per la visualizzazione. Due dispositivi in fusi diversi produrranno lo stesso timestamp Unix per lo stesso istante.
- Che cos'è il problema dell'anno 2038?
- I sistemi che memorizzano i timestamp Unix come interi con segno a 32 bit possono rappresentare solo valori fino a 2.147.483.647, che corrisponde al 19 gennaio 2038 alle 03:14:07 UTC. Dopo quell'istante l'intero va in overflow verso un grande numero negativo. I moderni sistemi a 64 bit non sono interessati, ma i sistemi embedded e i database legacy possono essere ancora a rischio.
- Che cos'è un timestamp Unix negativo?
- Un timestamp Unix negativo rappresenta un istante precedente all'epoch Unix. Per esempio, -86400 è il 31 dicembre 1969 alle 00:00:00 UTC. La maggior parte delle API di data moderne gestisce correttamente i timestamp negativi, ma alcuni sistemi e database più vecchi non li supportano.
- Come ottengo un timestamp Unix in Python?
- Usa import time; int(time.time()) per i secondi. Per un datetime UTC esplicito: import datetime; int(datetime.datetime.now(datetime.timezone.utc).timestamp()). Per i millisecondi: int(time.time() * 1000).
- Quanto è preciso un timestamp Unix?
- Un timestamp Unix standard ha precisione di un secondo. Per la precisione sotto il secondo, i timestamp in millisecondi (13 cifre) sono comuni nelle API web e in JavaScript. Alcuni sistemi usano microsecondi (16 cifre) o nanosecondi. L'unità appropriata dipende dalla precisione di cui la tua applicazione ha davvero bisogno.
- Quanto può essere grande un timestamp Unix?
- Su un intero con segno a 64 bit (lo standard odierno), i timestamp Unix possono rappresentare qualsiasi istante da circa 292 miliardi di anni fa a 292 miliardi di anni nel futuro. Il famoso limite a 32 bit (il problema dell'anno 2038) si applica solo ai sistemi legacy.
- Perché il mio timestamp mostra 1970?
- Di solito per uno di tre motivi: il valore è 0 (l'epoch stesso), il valore è in millisecondi ma è stato trattato come secondi (quindi si arrotonda a un valore di secondi minuscolo vicino a 0), oppure il valore è null/undefined e il tuo codice l'ha impostato per default a 0.
- Qual è la differenza tra UTC e GMT?
- Per la maggior parte degli scopi UTC e GMT sono intercambiabili. UTC (Tempo Coordinato Universale) è il moderno standard atomico; GMT (Greenwich Mean Time) è un termine legacy per il fuso a offset zero. Il Regno Unito e la maggior parte del software li trattano come equivalenti.
- Dovrei memorizzare le date come timestamp Unix o come stringhe ISO 8601?
- Funzionano entrambi. Gli interi Unix sono compatti e banali da confrontare; le stringhe ISO 8601 sono autodescrittive e leggibili dall'uomo. Nei database, i tipi datetime nativi (TIMESTAMP WITH TIME ZONE in Postgres, DATETIME(6) in MySQL) sono di solito i migliori perché preservano la semantica del fuso e indicizzano in modo efficiente.
- È sicuro memorizzare l'ora locale del mio server?
- No. Memorizzare l'ora locale senza un offset perde informazioni ogni volta che il server si sposta, cambia l'ora legale o un altro server in un fuso diverso legge il valore. Memorizza UTC (come timestamp Unix o datetime consapevole del fuso) e converti in ora locale solo nel livello di visualizzazione.
- I timestamp Unix includono i secondi intercalari?
- Il tempo Unix POSIX ignora deliberatamente i secondi intercalari — ogni giorno Unix è esattamente 86.400 secondi anche quando viene inserito un secondo UTC extra. Il numero di secondo effettivo viene ripetuto o l'orologio viene livellato, a seconda del sistema.