Mi az a Unix időbélyeg?

A Unix időbélyeg egyetlen szám: a Unix epoch óta eltelt másodpercek száma, amely 1970. január 1. 00:00:00 UTC-ként van meghatározva. Ennyi. Nincs időzóna, nincs dátumkarakterlánc, nincsenek hónapnevek – csak egy egész szám, amely másodpercenként egy egységgel növekszik.

Mivel az epoch fix és univerzális, egy olyan időbélyeg, mint a 1700000000, a Földön mindenhol ugyanazt a pillanatot jelenti. Egy tokói szerver és egy chicagói laptop egyaránt egyetért abban, hogy ez 2023. november 14-ét, 22:13:20 UTC-t jelöli. A helyi megjelenítés időzónánként eltér, de az alapul szolgáló szám soha.

Egy szándékos egyszerűsítés: a Unix idő figyelmen kívül hagyja a szökőmásodperceket. Feltételezi, hogy minden nap pontosan 86 400 másodperc hosszú, ami a csillagászati valóságban nem teljesen igaz, de tisztán tartja a számításokat. Erről bővebben lentebb.

Miért szeretik a mérnökök?

Az időbélyegek mindenhol jelen vannak a szoftverekben – fájlok módosítási ideje, adatbázisrekordok, API-válaszok, JWT lejárati mezők, naplósorok – és jó okkal:

• Egyetlen érték. Egyetlen egész szám tárol egy teljes dátumot és időt. Nincs értelmezés, nincs kétértelműség a HH/NN és NN/HH között.
• Időzóna-függetlenek. A szám mindig UTC. Csak akkor alakítod át helyi időre, amikor embernek mutatod.
• Könnyen összehasonlíthatók és rendezhetők. Melyik esemény történt előbb? A kisebb egész szám. Két esemény közötti időtartam? Vond ki őket; a válasz másodpercben van.
• Tömören tárolhatók. Egyetlen 4 vagy 8 bájtos egész szám egy formázott karakterlánccal szemben.

Ezért olyan sok infrastruktúra használ epoch másodperceket a motorháztető alatt, még akkor is, ha a felület egy barátságos 2026-07-23-at mutat. Ha a két reprezentáció között szeretnél váltani, egy Unix időbélyeg konverter mindkét irányban elvégzi a fordítást.

Egy időbélyeg értelmezése: Gyakorlati példa

Vegyük a 1000000000 időbélyeget – egy híreset, mert élő televízióban fordult át Unix-rajongók körében.

Kézzel történő értelmezéséhez a másodperceket nagyobb egységekre osztjuk. Nagyjából 1 000 000 000 másodperc körülbelül 31,7 év (egy év ~31 556 952 másodperc). Hozzáadva az 1970-es epochhoz, 2001-be érkezünk. A pontos pillanat 2001. szeptember 9., 01:46:40 UTC.

Ezt a számolást ritkán végzed el kézzel – minden nyelvben van beépített függvény. Pythonban:

```python from datetime import datetime, timezone datetime.fromtimestamp(1000000000, tz=timezone.utc)

2001-09-09 01:46:40+00:00

```

A lényeg: az átalakítás mindig UTC-hez van rögzítve. A függvény a nyers másodpercek számát naptári dátumokká alakítja az epochtól előre haladva. Ha helyi időt szeretnél, egy időzóna-eltolást alkalmazol az UTC-átalakítás után – maga az időbélyeg nem hordoz zónainformációt.

A 2038-as év problémája

Itt válik érdekessé a történet – és ahol sok egyébként jól felépített rendszerben egy ketyegő óra van.

Évtizedekig a Unix idő tárolására használt C szabványos típus, a time_t, általában egy előjeles 32 bites egész szám volt. Egy előjeles 32 bites egész szám −2 147 483 648-tól 2 147 483 647-ig terjedő értékeket képes reprezentálni. Ez a felső határ a probléma.

Az 1970-es epochtól számított másodperceket tekintve a 2 147 483 647 érték 2038. január 19., 03:14:07 UTC-kor érhető el. Egy másodperccel később a számlálónak 2 147 483 648-ra kellene nőnie – de ez a szám nem fér bele egy előjeles 32 bites egész számba. Ahelyett, hogy tovább nőne, a bitek túlcsordulnak és átfordulnak a legnegatívabb értékre, −2 147 483 648-ra.

Egy negatív időbélyeg az epoch előtti időként értelmeződik. Tehát az óra nem áll meg – visszaugrik 1901. december 13-ára. Bármely rendszer, amely megbízott a 32 bites time_t-jében, hirtelen azt hiszi, hogy a huszadik század elején jár.

Ezt gyakran Y2K38 hibának vagy Unix Millenniumi Hibának nevezik, és szerkezetileg ugyanaz a fajta fix szélességű túlcsordulás, amely a 2000-es év pánikját okozta – csak távolabbi és a bináris egész számok korlátaiban gyökerezik, nem pedig a kétjegyű években.

Hol csap le valójában?

A modern 64 bites asztali gépeket és szervereket évekkel ezelőtt nagyrészt kijavították. A kockázat a nehezen frissíthető helyeken összpontosul:

• Beágyazott és ipari rendszerek. Routerek, vezérlők, orvosi eszközök, autók ECU-i és IoT hardverek, amelyek 32 bites time_t-vel szállítottak és 20+ évig érintetlenül működhetnek. Sok ma telepített eszköz még 2038-ban is szolgálatban lesz.
• Örökölt C kód. Egy régi time_t definícióval lefordított alkalmazások, különösen ahol a típus bekerült a lemezes formátumokba vagy hálózati protokollokba.
• Régi adatbázisok és fájlrendszerek. Olyan tárolási formátumok, amelyek az időbélyegeket 32 bites mezőkbe csomagolták. Egyes régebbi rendszerek már most mutatnak tüneteket távoli jövőbeli dátumok kezelésekor – gondolj egy 20 éves jelzálogra vagy egy 2038 utáni tanúsítvány lejáratra.

A meghibásodási mód nem mindig drámai összeomlás. Néha egy finoman rosszul kiszámított dátum: egy lejárt token, amely érvényesnek olvasható, egy rendezési sorrend, amely megfordul, egy ütemezett feladat, amely 1901-ben indul el.

A javítás: 64 bites idő

Az orvosság elvileg egyértelmű – a time_t kiszélesítése 64 bitre. Egy előjeles 64 bites egész szám a gyakorlati horizonton túl is képes másodperceket számolni: a túlcsordulási pont nagyjából 292 milliárd év múlva van, kényelmesen a Nap várható élettartamán túl.

A legtöbb jelenlegi operációs rendszer már megtette ezt a lépést. A 64 bites Linux 64 bites time_t-t használ; még a 32 bites Linux is 64 bites időtámogatást kapott a kernelben és a glibc-ben az elmúlt években. A nehéz rész nem maga a javítás – hanem megtalálni és újrafordítani a firmware minden egyes darabját, minden tárolt formátumot és minden harmadik féltől származó binárist, amely még mindig 32 bitet feltételez. Ez az auditálási munka a valódi 2038-as projekt.

Hogyan illeszkednek bele a szökőmásodpercek?

A csillagászati idő és az atomi idő kissé eltávolodik egymástól, ezért a hivatalos UTC időnként beszúr egy szökőmásodpercet, hogy az órákat összhangban tartsa a Föld forgásával. A Unix idő tervezésénél fogva úgy tesz, mintha ezek nem léteznének – mereven 86 400 másodpercet ír elő naponta.

Amikor egy szökőmásodperc bekövetkezik, a rendszerek jellemzően "szétkenik" – elosztják a plusz másodpercet egy időablakon (a Google egy 24 órás kenést tett népszerűvé), hogy egyetlen órának se kelljen soha a lehetetlen 23:59:60-at mutatnia. A lényeg: a Unix időbélyegek simák és monotonok maradnak, azon az áron, hogy egy apró másodperctöredéknyire eltérnek a szigorú UTC-től a kenés alatt. Gyakorlatilag minden szoftver számára pontosan ez az a kompromisszum, amelyet akarsz. A 2038-as túlcsordulás egy egész szám szélességű probléma; a szökőmásodpercek egy különálló, sokkal kisebb definíciós furcsaság – ne keverd össze őket.

Főbb tanulságok

• A Unix időbélyeg az 1970. január 1. 00:00:00 UTC óta eltelt másodpercek száma, a szökőmásodperceket figyelmen kívül hagyva.
• Ez egyetlen, időzóna-független egész szám – könnyen tárolható, összehasonlítható és rendezhető.
• Az átalakítás mindig UTC-hez viszonyított; a helyi időt utólag alkalmazzuk.
• Az előjeles 32 bites time_t 2038. január 19., 03:14:07 UTC-kor csordul túl, negatív értékre fordulva és 1901-be ugrik.
• A javítás a 64 bites time_t; a munka a beágyazott és örökölt rendszerek auditálása.

Szeretnéd működés közben látni? Illessz be bármilyen epoch értéket a Unix időbélyeg konverter-be, hogy emberi dátumként olvasd – vagy menj az ellenkező irányba, és alakíts egy dátumot az időbélyegévé.

Gyakran Ismételt Kérdések

A Unix időbélyeg másodpercben vagy ezredmásodpercben van?

A klasszikus Unix idő másodpercben van. A JavaScript és sok webes API azonban ezredmásodperceket használ az epoch óta, így egy 1700000000000 érték 1000× nagyobb. Gyors támpont: egy másodperc alapú időbélyeg egy közelmúltbeli dátumhoz 10 számjegyű; egy ezredmásodperc alapú 13. Ha kétségeid vannak, ellenőrizd a nagyságrendet az átalakítás előtt.

A 2038-as év problémája összeomlasztja a telefonomat vagy laptopomat?

Szinte biztosan nem. A modern 64 bites operációs rendszerek már 64 bites time_t-t használnak, ami milliárd évekre tolja ki a túlcsordulást. A valódi kitettség a hosszú élettartamú beágyazott eszközökben és a régi szoftverekben van, amelyek még mindig 32 bites időre támaszkodnak, és lehet, hogy 2038 előtt nem frissítik őket.

Lehet negatív egy Unix időbélyeg?

Igen. A negatív értékek az 1970-es epoch előtti pillanatokat reprezentálják – például a -1 1969. december 31., 23:59:59 UTC. Pontosan ezt produkálja a 32 bites túlcsordulás 2038-ban, ezért tűnik úgy, hogy az óra visszaugrik 1901-be.

Miért hagyja figyelmen kívül a Unix idő a szökőmásodperceket?

Hogy a matematika egyszerű és kiszámítható maradjon. Ha minden napot pontosan 86 400 másodpercként kezelünk, az időtartamok egyszerű kivonások, és az időbélyegek monotonok maradnak. A csillagászati UTC-vel való kis eltérést a szökőmásodperc "kenésével" kezelik, amit szinte minden alkalmazás előnyben részesít a 23:59:60 éllel való foglalkozással szemben.

Hogyan alakíthatok át egy időbélyeget kód írása nélkül?

Használj egy online eszközt. A Unix időbélyeg konverter elfogad egy epoch értéket, és azonnal megmutatja a hozzá tartozó UTC és helyi dátum-időt, valamint a naptári dátumokat is visszaalakítja időbélyegekké.