L’idea in una frase
Un timestamp Unix conta i secondi (a volte i millisecondi) trascorsi da un’epoca concordata: 1970-01-01T00:00:00Z—mezzanotte UTC del 1° gennaio 1970—escludendo i secondi intercalari nella definizione POSIX abituale. Quell’intero singolo memorizza un istante senza etichetta di fuso orario.
Convertite un valore numerico in data leggibile con lo strumento timestamp Unix in data.
Perché agli ingegneri piacciono i secondi d’epoca
Le date civili richiedono calendari, fusi e ora legale. Eventi istantanei—«questo ordine è stato pagato», «questo certificato scade», «questa riga di log è stata scritta»—sono più semplici come conteggio monotono da un’origine fissa. Il tempo Unix viaggia bene tra linguaggi, database e API. Ordinare timestamp è ordinare interi; le differenze sono sottrazioni.
Il costo è la leggibilità umana: 1710000000 dice poco finché non lo convertite. Strumenti e formattatori di libreria colmano il divario.
Secondi versus millisecondi versus nanosecondi
Le convenzioni differiscono:
| Unità | Uso tipico | Lunghezza esempio (anni 2020) |
|---|---|---|
| Secondi | POSIX, molte API | 10 cifre |
| Millisecondi | JavaScript Date, alcuni DB | 13 cifre |
| Micro/nano | Metriche ad alta risoluzione | interi più lunghi |
Passare millisecondi a un’API che aspetta secondi produce date lontane. Passare secondi a un’API a millisecondi atterra vicino al 1970. In integrazione, controllate la documentazione e provate con un istante noto.
Date.now() in JavaScript restituisce millisecondi. Molti framework backend usano secondi di default. Siate espliciti nei nomi JSON (createdAtSeconds) quando possibile.
UTC e visualizzazione locale
Il timestamp in sé è basato su UTC. Mostrarlo a Berlino o Tokyo applica una conversione di fuso per gli umani; l’intero memorizzato non cambia. Conservate istanti UTC e localizzate ai bordi—UI, e-mail, report.
Timestamp negativi e futuri lontani
I timestamp precedenti al 1970 sono negativi sui sistemi che li supportano. Date molto lontane possono overfloware interi signed a 32 bit: il classico problema dell’anno 2038 per time_t su piattaforme a 32 bit. Il time_t moderno a 64 bit spinge l’overflow ben oltre gli orizzonti pratici a risoluzione di secondo. Preferite tipi a 64 bit nei sistemi nuovi.
Secondi intercalari (livello di consapevolezza)
UTC inserisce a volte secondi intercalari. Il tempo Unix POSIX tipicamente li ignora, trattando ogni giorno come 86 400 secondi. Per le app business quotidiane va bene. Per astronomia, telecom o timestamping legale al secondo attraverso i salti, studiate la scala del vostro settore (UTC, TAI, tempo GPS) e il supporto delle librerie.
ISO 8601 accanto al tempo Unix
Le API spesso accettano entrambi:
17100000002024-03-09T16:00:00Z
Stringhe ISO 8601 con Z o offset numerico comunicano lo stesso istante se il parsing è corretto. Il tempo Unix è compatto; le stringhe ISO si cercano bene nei log. Molti sistemi memorizzano interi ed emettono ISO in JSON.
Flusso di conversione
- Identificare l’unità (s/ms).
- Interpretare il numero come epoca UTC.
- Formattare con zona esplicita per la visualizzazione.
- Andata e ritorno: formattare e parsare, o riconvertire in epoca, per confermare l’accordo.
La conversione a mano senza libreria è propensa a errori vicino a lunghezze dei mesi e anni bisestili—usate librerie collaudate in produzione.
Database e indicizzazione
Memorizzate interi d’epoca o tipi timestamp nativi che normalizzano a UTC. Evitate l’ora civile locale senza zona se intendete un istante. Indicizzare epoche intere è diretto; documentate l’unità nei commenti di schema.
Per «date di business» come giorni di fattura, un tipo data senza ora può essere meglio di un’epoca a mezzanotte—politica e giurisdizione definiscono cosa significa «il giorno».
Logging e osservabilità
I processori di log amano il tempo Unix. Correlate le tracce tra servizi nello stesso dominio di orologio quanto possibile. Lo skew di clock tra host esiste ancora—NTP aiuta—tollerare piccoli negativi nelle durate e preferire timestamp generati sul server per audit trail autorevoli.
Bug comuni
- Mismatch di unità (secondi vs millisecondi).
- Trattare l’epoca come locale formattando senza
Z. - Matematica su stringhe di date invece che su istanti.
- Excel converte i timestamp con epoche sbagliate (il giorno zero di Excel differisce).
- Overflow a 32 bit su sistemi embedded o legacy.
Esempio didattico
Prendete un timestamp, convertitelo in UTC, poi in due fusi civili. Confermate che entrambe le stringhe civili riferiscono lo stesso istante. Quell’esercizio costruisce intuizione meglio di memorizzare formule.
Usate from-unix-timestamp-to-date per ispezionare valori da API o dump di database (campioni non sensibili).
Concetti correlati
- Gli orologi monotoni misurano il tempo trascorso e non devono tornare indietro; non sono timestamp Unix e non vanno persistiti come ora di parete.
- Le espressioni cron descrivono pianificazione civile, non epoche.
- I campi
notAfterdei certificati sono istanti—confrontateli in UTC.
Riepilogo
I timestamp Unix codificano istanti come conteggi dal 1970-01-01 UTC. Semplificano archiviazione e ordinamento spingendo la formattazione umana ai bordi. Conoscete le unità, usate tipi a 64 bit, visualizzate con zone esplicite e convertite con strumenti affidabili quando un numero grezzo deve diventare una data di calendario.