Convertor Timestamp Unix

Convertește orice marcaj temporal Unix într-o dată și o oră ușor de înțeles.

Convertorul nostru:

• detectează automat secundele (10 cifre) și milisecundele (13 cifre)
• afișează ora UTC și ora locală
• prezintă mai multe formate, inclusiv ISO 8601 și RFC 2822

Convertește orice dată și oră în marcajul său temporal Unix.

Selectează o dată, alege fusul orar și obține timpul epoch atât în secunde, cât și în milisecunde.

Perfect pentru:

• dezvoltare API
• interogări de baze de date
• depanarea problemelor legate de timp

Timpul Unix este un sistem de urmărire a unui punct în timp ca număr de secunde scurse de la epoca Unix, definită ca 00:00:00 UTC la 1 ianuarie 1970. IEEE și The Open Group codifică acest lucru în standardul POSIX (IEEE Std 1003.1), unde este numit oficial „Secunde scurse de la epocă” (Seconds Since the Epoch).

A O nuanță cheie documentată de POSIX este că timpul Unix ignoră în mod deliberat secundele salt (leap seconds), astfel încât fiecare zi este tratată exact ca având 86.400 de secunde. Deoarece valoarea este un singur număr întreg independent de fusul orar, ea este neambiguă în toate sistemele.

Stocarea timpului ca număr întreg, așa cum menționează MDN Web Docs pentru obiectul Date din JavaScript, face ca aritmetica și comparația să fie banale în comparație cu parsarea șirurilor de date formatate.

Un marcaj temporal Unix de 10 cifre numără secundele de la epocă, în timp ce unul de 13 cifre numără milisecundele, iar combinarea lor este cea mai comună eroare de conversie.

Conform MDN Web Docs, funcțiile Date.now() și getTime() din JavaScript returnează milisecunde, deci 1700000000000 este o valoare JS validă. Spre deosebire de acestea, funcțiile POSIX C precum time() și time.time() din Python (prin truncare), plus majoritatea bazelor de date SQL și comanda date +%s din Bash, operează în secunde (1700000000).

Pentru a le converti între ele, înmulțește secundele cu 1.000 sau împarte milisecundele la 1.000.

Convertorul nostru detectează automat unitatea după numărul de cifre, dar atunci când scrii cod, trebuie să confirmi întotdeauna ce unitate așteaptă limbajul sau API-ul tău pentru a evita datele care aterizează în 1970 sau peste mii de ani în viitor.

Poți genera marcajul temporal Unix curent printr-un singur apel în aproape fiecare limbaj de programare.

• În JavaScript, MDN Web Docs recomandă Math.floor(Date.now() / 1000) pentru secunde sau Date.now() pentru milisecunde.
• În Python, time.time() returnează un număr cu virgulă flotantă reprezentând secundele de la epocă, potrivindu-se cu funcția time() din biblioteca C definită de POSIX.
• În linia de comandă, date +%s din GNU coreutils afișează marcajul temporal curent cu precizie de secundă, în timp ce PHP folosește time(), iar Go folosește time.Now().Unix().
• Motoarele SQL expun funcții precum UNIX_TIMESTAMP() în MySQL și EXTRACT(EPOCH FROM now()) în PostgreSQL.

Toate acestea fac referire la aceeași origine 1970 UTC, astfel încât valorile sunt direct interschimbabile odată ce normalizezi unitatea de secunde versus milisecunde.

Folosește un marcaj temporal Unix pentru stocare și operații aritmetice și ISO 8601 pentru schimbul de date în format ușor de citit de către oameni și pentru jurnale (log-uri).

ISO 8601 este standardul internațional pentru reprezentarea datelor și orelor ca șiruri de caractere precum 2023-11-14T22:13:20Z, unde litera majusculă T separă data de oră, iar Z de la sfârșit indică timpul UTC (ora Zulu). Aceste litere țin cont de majuscule și minuscule, așa că, dacă cureți șiruri copiate din surse cu majuscule mixte, o scurtă trecere printr-un convertor de majuscule le menține parsabile. RFC 3339 al IETF personalizează ISO 8601 pentru utilizare pe internet și este adoptat de majoritatea API-urilor JSON pentru câmpurile de dată, deoarece JSON în sine (RFC 8259) nu are un tip de dată nativ.

Un număr întreg Unix este mai compact și neutru din punct de vedere regional, dar nu este auto-explicativ, în timp ce un șir ISO 8601 este lizibil instantaneu. Multe sisteme stochează numărul întreg intern și îl serializează în ISO 8601 la granița API-ului pentru a obține beneficiile ambelor variante.

Un marcaj temporal Unix nu are fus orar, deoarece face întotdeauna referire la un singur moment măsurat de la epocă în UTC. Fusurile orare contează doar atunci când afișezi acel moment ca o dată calendaristică pentru un utilizator.

Baza de date a fusurilor orare IANA (baza de date tz) este sursa autorizată pe care sistemele de operare și limbajele o folosesc pentru a mapa un moment la ora locală, inclusiv regulile istorice de trecere la ora de vară.

Cea mai bună practică, susținută de MDN Web Docs și nenumărate ghiduri de inginerie, este să stochezi și să transmiți marcajele temporale în UTC și să le convertești în fusul orar local al utilizatorului doar în momentul afișării. Acest lucru elimină ambiguitatea legată de tranzițiile la ora de vară și face ca comparațiile între regiuni să fie fiabile și reproducibile.

Problema anului 2038 reprezintă momentul în care numerele întregi cu semn pe 32 de biți care stochează timpul Unix vor depăși capacitatea maximă, acest lucru întâmplându-se la 03:14:07 UTC pe 19 ianuarie 2038.

O valoare cu semn pe 32 de biți atinge maximul la 2.147.483.647 secunde; o secundă mai târziu, contorul se dă Peste cap și devine un număr negativ mare, pe care codul neoptimizat îl interpretează greșit ca fiind 19 decembrie 1901. Această situație oglindește îngrijorarea istorică legată de problema Anului 2000, dar își are rădăcinile în lățimea fixă a tipului time_t din C pe platformele vechi.

Sistemele de operare și limbajele moderne au migrat în mare parte către time_t pe 64 de biți, ceea ce împinge momentul depășirii cu aproximativ 292 de miliarde de ani în viitor. Sistemele încorporate și formatele vechi de fișiere rămân principalele zone de risc pe care dezvoltatorii ar trebui să le auditeze.

Timestamps Unix reprezintă coloana vertebrală a gestionării timpului în sistemele backend, jurnale (logs) și API-uri, deoarece pot fi sortate, scăzute și comparate ca simple numere întregi.

Baze de date stochează coloanele created_at și updated_at ca valori epoch sau tipuri de timp derivate din acestea, iar straturile de cache folosesc timestamp-uri de expirare pentru a invalida înregistrările. Tokenurile de securitate se bazează de asemenea pe ele: standardul JWT, RFC 7519, definește cererile (claims) exp (expirare) și iat (emis la) ca valori NumericDate, care sunt literalmente secunde de la epoca Unix.

Jurnalele distribuite și fluxurile de evenimente folosesc timestamp-uri pentru a stabili ordonarea, iar mecanismele de limitare a ratei (rate limiters) compară epoca curentă cu ferestrele stocate. Natura lor independentă de limbaj le face ideale pentru transmiterea timpului dincolo de granițele serviciilor.

Timestamp-urile Unix negative reprezintă momente anterioare epocii, astfel încât -86400 corespunde datei de 31 decembrie 1969 la ora 00:00:00 UTC. Definiția POSIX permite ca numărul de secunde să fie negativ, iar limbaje precum JavaScript respectă acest lucru: MDN Web Docs documentează faptul că obiectul Date acceptă valori negative în milisecunde pentru a exprima date anterioare anului 1970.

Acest lucru este util pentru date istorice, zile de naștere sau arhive.

Totuși, fiți atenți deoarece unele sisteme mai vechi, baze de date și instrumente pe 32 de biți tratează timpul Unix ca fiind fără semn sau resping intrările negative, ajustând silențios valoarea la epocă sau generând o eroare. Când gestionați date istorice, verificați dacă fiecare strat al stivei dvs., de la tipul de coloană din baza de date până la biblioteca client, acceptă timestamp-uri cu semn.

• Cea mai frecventă greșeală este confundarea secundelor cu milisecundele, ceea ce generează date greșite cu decenii sau blocate în 1970. Confirmați întotdeauna unitatea pe care o folosește sursa dvs. înainte de conversie, deoarece JavaScript emite milisecunde, în timp ce majoritatea backend-urilor emit secunde.
• O a doua capcană este să presupuneți că un timestamp conține un fus orar; nu conține, așa că aplicarea unui decalaj local de două ori duce la ore inexacte.
• Altele includ ignorarea limitei anului 2038 pentru câmpurile pe 32 de biți și așteptarea ca timpul Unix să ia în considerare secundele intercalare (leap seconds), pe care POSIX le exclude în mod explicit.
• În cele din urmă, evitați analizarea manuală a șirurilor de date formatate; folosiți biblioteci standard și preferați ISO 8601 (RFC 3339) pentru schimbul de date, după cum recomandă MDN Web Docs, pentru a evita formatele ambigue precum LL/ZZ versus ZZ/LL.