Convertor de timestamp Unix în dată

Ce este un Unix timestamp?

Un Unix timestamp, cunoscut și ca Unix time sau POSIX time, este numărul de secunde care au trecut de la 1970-01-01 00:00:00 UTC, cunoscut ca epoca Unix. Este un standard larg răspândit în informatică deoarece reprezintă un moment în timp ca un singur întreg, ceea ce face stocarea, compararea și calculele foarte simple.

JavaScript lucrează intern în milisecunde, deci Date.now() returnează Unix timestamp înmulțit cu 1000. Multe API-uri, baze de date și sisteme backend folosesc în schimb secunde. Acest instrument acceptă ambele formate și detectează automat dacă ați introdus secunde sau milisecunde, în funcție de mărimea numărului.

Unix timestamps notabile

De ce 1970?

Epoca Unix de 1 ianuarie 1970 a fost aleasă parțial prin convenție și parțial din motive practice. Unix a fost dezvoltat la sfârșitul anilor 1960 și începutul anilor 1970 la Bell Labs. Dezvoltatorii aveau nevoie de o dată de începere recentă și rotundă pentru reprezentarea timpului. 1 ianuarie 1970 era recent suficient pentru a fi practic și nu avea o semnificație tehnică specială — era pur și simplu un punct de referință convenabil.

Alte sisteme folosesc date diferite pentru epoca lor: epoca Windows FILETIME este 1 ianuarie 1601; GPS time a început pe 6 ianuarie 1980; epoca NTP este 1 ianuarie 1900. Când convertite între sisteme, cunoașterea epocii fiecărui sistem este esențială.

Secunde versus milisecunde

Unix timestamp original este exprimat în secunde. Majoritatea limbajelor și sistemelor server-side (Unix shell, time.time() în Python, time() în PHP, majoritatea bazelor de date) folosesc secunde. Date.now() și new Date().getTime() din JavaScript returnează milisecunde. Această discrepanță este o sursă comună de erori atunci când frontend-urile JavaScript comunică cu API-uri backend.

Un Unix timestamp în secunde este în prezent un număr cu 10 cifre (aproximativ 1.700.000.000 la data din 2023). Un timestamp în milisecunde este un număr cu 13 cifre. Calculatorul detectează care format ați introdus pe baza numărului de cifre și convertește corespunzător.

Problema anului 2038

Sistemele care stochează Unix timestamp-uri ca întregi cu semn pe 32 de biți pot reprezenta doar date până la 2.147.483.647 secunde după epocă — adică 03:14:07 UTC pe 19 ianuarie 2038. După acel moment, un întreg cu semn pe 32 de biți se va inversa la un număr negativ mare, reprezentând o dată din 1901.

Aceasta se numește uneori problema "Y2K38" sau Unix Millennium Bug. Sistemele moderne pe 64 de biți nu sunt afectate, deoarece un întreg cu semn pe 64 de biți poate reprezenta timestamp-uri pentru aproximativ 292 de miliarde de ani. Cu toate acestea, sistemele embedded, bazele de date moștenite și software-ul mai vechi pe 32 de biți pot fi încă vulnerabile. Multe industrii — inclusiv telecomunicațiile, banca și sistemele de control industrial — au eforturi continue de migrare pentru a aborda aceasta.

Cum să obțineți Unix timestamp-ul actual

Utilizări practice

Dezvoltarea API: REST API-urile folosesc frecvent Unix timestamp-uri pentru câmpurile created_at, updated_at și expirarea tokenilor. Un timestamp este independent de fus orar și neambiguu — spre deosebire de șirurile de date formatate, care depind de localizare și convenții de formatare.

Expirarea tokenilor: JWT (JSON Web Tokens) folosesc Unix timestamp-uri pentru claimurile exp (expirare) și iat (emis la). Un token expiră atunci când timestamp-ul actual depășește valoarea exp. Calcularea timpilor de expirare — "acest token ar trebui să expire în 24 de ore" — necesită adunarea a 86.400 de secunde la timestamp-ul actual.

Cache TTL: Expirarea cache-ului este adesea setată ca Unix timestamp sau ca un număr de secunde de acum. Depanarea problemelor de cache necesită frecvent convertirea unui timestamp de expirare stocat la o dată lizibilă omului.

Analiza jurnalelor: Jurnalele server includ adesea Unix timestamp-uri. Convertirea acestora la date lizibile este primul pas în corelarea intrărilor jurnalului cu evenimente din lumea reală.

Stocarea în baze de date: Stocarea timestamp-urilor ca întregi mai degrabă decât ca șiruri formatate evită erorile de conversie a fusului orar și simplifică sortarea, interogări de interval și calcule. O interogare pentru "toate înregistrările din ultimele 7 zile" devine WHERE created_at > (NOW_UNIX - 604800).