Unix Timestamp Converter: Epochs, Timezones en de Year-57123-bug

Een gebruiker van een van mijn Laravel SaaS-apps die ooit een e-mail stuurde om te zeggen dat zijn verlengingsdatum voor het abonnement er "een beetje genereus uitzag". 57123.

De bug kostte me beschamend lang om te vinden omdat elk afzonderlijk stuk correct was. De React-frontend verzonden Date.now()- wat terugkeert milliseconden- en de PHP-backend deed dat ook date('Y-m-d', $timestamp), die verwacht tweede soort. gebruiken 1740470400000 in een functie verwachten 1740470400 En je landt ongeveer 55.000 jaar in de toekomst. Geen uitzondering, geen waarschuwing, geen mislukte test. Gewoon een klant die beleefd vroeg of zijn abonnement echt duurde tot de hittedood van de beschaving.

Timetempels zien eruit als het saaiste onderwerp in software. Ze zijn eigenlijk een van de meest betrouwbare bugfabrieken die we hebben: seconden versus milliseconden, UTC versus lokale, DST-overgangen, de 2038-rollover. de tijdstempel converter op Toolz.dev bestaat omdat ik het beu was om te doen new Date(x * 1000) In een browserconsole veertig keer per dag. Deze gids behandelt wat ik nu controleer, in de volgorde die ik controleer.

tl;dr: Een UNIX-tijdstempel telt seconden sinds 1970-01-01T00:00:00 UTC. 10 cijfers = seconden, 13 cijfers = milliseconden- door ze door elkaar te halen, komen je data 55.000 jaar vrij. Bewaar UTC, converteer alleen voor weergave, gebruik IANA-zonenamen zoals Asia/Dhaka in plaats van afkortingen. Plak een willekeurige tijdstempel in de tijdstempel converter om ISO 8601, RFC 2822, lokale en UTC-formulieren te krijgen, draait het aan de clientzijde, dus tijdstempels uit JWTS En productielogboeken verlaten nooit uw browser.

Wat is precies een UNIX-tijdstempel precies?

Een UNIX-tijdstempel (Epoch-tijd, Posix-tijd) is het aantal seconden dat is verstreken sinds 1 januari 1970, 00:00:00 UTC- de "Unix epoch." It's een enkel geheel getal, het heeft geen tijdzone (it' s altijd UTC per definitie), en effectief elke OS, taal en database begrijpt het Die laatste eigenschap is waarom het vijf decennia heeft overleefd: het is de enige tijd formaat waar niemand ruzie over maakt.

Waarom 1970? geen diepe reden - het was een handige ronde datum in de buurt van toen Unix werd gebouwd bij Bell Labs, en vroege Unix telde de tijd in een 32-bit geheel getal De willekeurige keuze versteende tot een universele standaard, die erg Unix is.

Enkele referentiepunten die het waard zijn om op zicht te herkennen:

Die vierde rij is om een subtiele reden mijn favoriete voorbeeld: veel lijst met zelfstudiepagina's 1740470400 Als "Feb 25, 2025, 12:00:00." het is eigenlijk 08:00 UTC- iemand heeft het een keer in zijn lokale tijdzone omgezet en sindsdien is de verkeerde waarde gekopieerd. Controleer tijdstempels met een tool, niet met een blogpost. Inclusief deze.

Seconden of milliseconden - Hoe vertel je het?

Tel de cijfers. Voor elke datum in het huidige tijdperk:

• 10 cijfers ((1740470400) - seconden. Unix-conventie, de meeste API's, PHP's time(), Python's time.time() (als een praalwagen), Stripe's API.
• 13 cijfers ((1740470400000) - milliseconden. JavaScript's Date.now(), Java's System.currentTimeMillis(), MongoDB-data.

Dit is het exacte onderscheid dat mijn jaar-57123-verlengingsdatum opleverde, dus ik zal de faalwijzen omschrijven:

• MS geïnterpreteerd als seconden → dateert ~55.000 jaar in de aanstaande
• Seconden geïnterpreteerd als MS → Data in Januari 1970 (Alles stort in tot ~3 weken na het tijdperk)

Als je een van beide handtekeningen ziet - oude data of absurde data uit de verre toekomst - ken je de bug voordat je een regel code leest. De tijdstempel converter Detecteert het aantal cijfers en labelt beide interpretaties, die de "Is deze S of MS?'-argument in twee seconden beslecht.

Welke datumformaten moet u eigenlijk weten?

Drie bestrijken bijna alles wat een werkende ontwikkelaar aanraakt.

ISO 8601- de internationale standaard, en wat u moet uitstoten in API's en logboeken:

2026-07-13T09:30:45Z          UTC ("Z" = Zulu)
2026-07-13T15:30:45+06:00     with timezone offset
2026-07-13T09:30:45.123Z      with milliseconds

De moordende functie die niemand noemt: ISO 8601-snaren sorteer lexicografisch in chronologische volgorde. sort Op een logbestand werkt het gewoon. 02/25/2026-stijlformaten kunnen' Dat doen - en erger nog, VS MM/DD en Europese DD/MM zijn niet te onderscheiden gedurende twaalf dagen van elke maand.

RFC 3339 ((speculatie) - het internetprotocolprofiel van ISO 8601. Iets strenger; als uw API uitzendt 2026-07-13T09:30:45Z Je bevredigt beide. Dit is het formaat om op te standaardiseren.

RFC 2822 ((Sun, 13 Jul 2026 09:30:45 +0000) - e-mail en HTTP headers, RSS feeds Je leest het vaker dan dat je het schrijft.

Databaseformaten zijn naaste neven: MySQL DATETIME is 2026-07-13 09:30:45 (ISO met een spatie), postgresql timestamptz blaver 2026-07-13 09:30:45+00.

Hoe gaan de talen die ik gebruik om met tijdstempels?

De drie uit mijn eigen stapel - en de eigenaardigheid in elk die mij persoonlijk tijd heeft gekost.

javascript (de MS-):

Math.floor(Date.now() / 1000)        // current Unix seconds — Date.now() is ms!
new Date(1740470400 * 1000)          // seconds → Date: multiply by 1000
date.toISOString()                   // "2025-02-25T08:00:00.000Z"
Date.parse('2026-07-13T09:30:45Z') / 1000   // ISO string → Unix seconds

Quirk: alles is milliseconden, en new Date(1740470400) Stilte geeft je 21 januari 1970 in plaats van februari 2025. Geen fout. Deze asymmetrie is de meest voorkomende tijdstempelbug in webontwikkeling.

PHP (de seconden):

time();                                   // current Unix seconds
date('Y-m-d H:i:s', 1740470400);          // "2025-02-25 08:00:00" (server TZ!)
strtotime('2026-07-13 09:30:45');         // string → timestamp
(new DateTime('@1740470400'))
    ->setTimezone(new DateTimeZone('Asia/Dhaka'))
    ->format(DateTime::ATOM);             // "2025-02-25T14:00:00+06:00"

Ruk: date() formaten in de servers Standaard tijdzone, dus dezelfde code drukt verschillende datums af op uw machine en in productie. ook, new DateTime('@1740470400') negeert elke tijdzone die u doorgeeft aan de constructor - de @ formulier is altijd UTC; u moet bellen setTimezone() na. WordPress voegt zijn eigen laag toe: current_time('timestamp') Retourneert een nep "local" tijdstempel offset van echte Unix-tijd, wat precies zo gevaarlijk is als het klinkt.

pydonpiepsel

import time, datetime
int(time.time())                                      # current Unix seconds
datetime.datetime.fromtimestamp(1740470400,
    tz=datetime.timezone.utc)                         # → aware datetime
dt.isoformat()                                        # "2025-02-25T08:00:00+00:00"

Ruk: fromtimestamp() buiten tz= Retourneert een naïeve datetime in de lokale tijd. Naïeve datetimes zijn de Python Time-bug: ze vergelijken en trekken gelukkig tegen elkaar af totdat de dag één van hen een DST-grens overschreed. altijd voorbij gaan tz=; gebruik zoneinfo (Stdlib sinds 3.9) voor genoemde zones.

Hoe moet je omgaan met tijdzones zonder gek te worden?

Vier regels, allemaal geleerd op de vervelende manier:

1. bewaar utc. Altijd. Unix-tijdstempels of timestamptz in de database. Tijdzone wordt alleen een weergave van zorg.
2. Converteren op de presentatielaag. De gebruiker in Dhaka ziet +06:00, ziet de gebruiker in Berlijn +02:00, ziet de database geen van beide.
3. Gebruik IANA-namen, geen afkortingen. Asia/Dhaka, America/New_York, Europe/Berlin. Afkortingen zijn dubbelzinnig - CST betekent Centrale Amerikaanse, Chinese standaardtijd of Cuba-standaardtijd, afhankelijk van wie's lezen - en afkortingen don't coderen DST-regels. IANA-namen doen.
4. Nooit met de hand rollen DST-logica. DST-data verschillen per land, wijziging door wetgeving en sommige plaatsen (Arizona, Bangladesh, Japan) observeren DST helemaal niet. De IANA TZ-database bestaat omdat dit echt moeilijk is; gebruik de bibliotheek die het omhult.

Het uitvloeisel van regel 1: Wanneer twee systemen het oneens zijn over een gebeurtenistijd, converteren ze beide waarden naar UTC UNIX-tijdstempels en vergelijkt ze de gehele getallen. Argumenten over "maar er staat hier 15.00 uur" Oplossen onmiddellijk.

Wat is het Y2038-probleem en moet u erom geven?

Een 32-bits ondertekend geheel getal maximaliseert het 2,147,483,647. Als een Unix-tijdstempel, dat is 19 januari 2038, 03:14:07 UTC. Een seconde later wordt de waarde negatief - tot 13 december 1901.

Klinkt ver weg; het is ' t, om twee redenen Ten eerste, it & #39; s ongeveer 11,5 jaar uit terwijl ik dit schrijf - ruim binnen de levensduur van embedded systemen, industriële controllers, en die ene legacy service die niemand wil aanraken Tweede, aanstaande Datums raakten vroeg de muur: een systeem dat een 15-jarig hypotheekschema berekent of een 20-jarig certificaat vervalt 2038 op de huidige dag. mysql's TIMESTAMP kolomtype is de klassieke val - it's 32-bit begrensd en can't bewaardata na 19-01-2038, terwijl DATETIME In dezelfde database is het prima.

Je bent veilig op 64-bits time_t (elk modern besturingssysteem), JavaScript (Float 64 ms), Python (willekeurige precisie) en PostgreSQL. Je loopt risico op 32-bits embedded systemen, oude TIMESTAMP kolommen en C-code die hardcoded is int32_t voor tijd. De test is eenvoudig: push 2147483648 (één over de limiet) via uw pijplijn en kijk wat er uitkomt. de tijdstempel converter zal u graag de testwaarden na 2038 genereren.

Waar verschijnen tijdstempels in echt debuggen?

JWT vervalt. tokens dragen iat en exp Claims als Unix-seconden:

{ "sub": "user_8241", "iat": 1783915890, "exp": 1783919490 }

"Waarom wordt deze gebruiker uitgelogd?" wordt beantwoord door te converteren exp. decodeer het token in de JWT-decoder en converteer de claim - beide draaien client-side, wat belangrijk is omdat een geplakt token een live-referentie is (de Gids voor gegevensprivacy Dekt waarom ik weiger tokens in server-side tools te plaatsen).

logboek correlatie. Eén incident, drie services, drie formaten: Nginx-logboeken [13/Jul/2026:09:30:45 +0000], de app registreert ISO 8601, een wachtrijmedewerker logt onbewerkte tijdperken in. Alles converteren naar één formaat is stap nul van het bouwen van een tijdlijn.

API-integratie. Gestreepte stuurt "created": 1740470400 (seconden). Een JavaScript-gebouwde API verzendt 1740470400000 (ms). Google API's verzenden RFC 3339-strings Als u ze alle drie verbruikt, is conversie ' t occasioneel - it' s constant Formatteer de payloads in de JSON-formatter en converteer de interessante velden.

query's voor datumbereik. WHERE created_at >= 1752364800 AND created_at < 1752451200- is dat de juiste dag? Converteer beide grenzen en controleer, in UTC, voordat u de Verwijderen uitvoert. Verwant: de Datumverschil rekenmachine voor "Hoeveel dagen tussen deze twee?", de tijdzone-omzetter voor de vergadertijd wiskunde en de croonparer voor "Wanneer brandt dit schema eigenlijk?".

Veelgestelde vragen

Wat is een Unix-tijdstempel?

Het aantal seconden dat is verstreken sinds 1 januari 1970, 00:00:00 UTC (het Unix-tijdperk), opgeslagen als een enkel geheel getal. It's tijdzone-onafhankelijk per definitie - hetzelfde moment is overal op aarde hetzelfde getal - daarom is het ' is het standaard uitwisselingsformaat tussen besturingssystemen, talen en databases.

Waarom hebben sommige tijdstempels 10 cijfers en andere 13?

10 cijfers is seconden (standaard UNIX-conventie, PHP, de meeste API's); 13 cijfers is milliseconden (JavaScript's Date.now(), Java). Deel door 1.000 om van MS naar seconden te gaan. Het verwarren van de twee ploegen dateert ofwel ~55.000 jaar in de toekomst of terug tot januari 1970.

Kunnen Unix-tijdstempels datums vóór 1970 vertegenwoordigen?

Ja - negatieve waarden tellen terug vanaf het tijdperk. -86400 is 31 december 1969. Een 32-bits ondertekende tijdstempel reikt terug tot 13 december 1901. Sommige systemen en API's weigeren echter negatieve tijdstempels, dus test voordat u erop vertrouwt.

Wat is het Y2038-probleem?

32-bits ondertekende tijdstempelsoverflow bij 2.147.483.647 - 19 januari 2038, 03:14:07 UTC - inpakken tot december 1901 Moderne 64-bits systemen worden niet beïnvloed, maar 32-bits ingebedde apparaten, oudere C-code en MySQL TIMESTAMP kolommen worden blootgesteld. Systemen die verre toekomstige data (hypotheken, certificaten) hebben bereikt, raakten de bug jaren voordat 2038 arriveert.

Waarom wordt mijn date weergegeven in januari 1970?

Een nul of bijna-nul tijdstempel bereikte uw opmaakcode - meestal een niet-geïnitialiseerde waarde, een mislukte parse die 0 retourneert, of seconden die voorbijgaan waar milliseconden werden verwacht Een datum op het scherm uit 1970 is bijna nooit een datapunt; it' is een nul die een kostuum draagt.

Moet ik tijdstempels of datetime-strings opslaan in mijn database?

Sla UTC hoe dan ook op - het type doet er minder toe dan de tijdzonediscipline Unix gehele getallen zijn compact, sorteren triviaal en ontwijken het parseren volledig; timestamptz/DATETIME kolommen zijn voor mensen leesbaar in queryresultaten en rekenkunde van ondersteuningsdatums in SQL. Wat u niet mag doen, is lokale tijden opslaan zonder offsets - that's gegevensverlies dat u pas ontdekt bij de volgende zomertijdovergang.

Wordt het tijdperk beïnvloed door schrikkelseconden?

Praktisch, nee. Unix-tijd doet alsof schrikkelseconden don't bestaan - elke dag is precies 86.400 seconden, en systemen smeren of stappen doorgaans de klok wanneer er een schrikkelseconde optreedt Voor applicatiecode is dit een non-issue; het doet er alleen toe in wetenschappelijke timingcontexten, waar in plaats daarvan TAI- of GPS-tijd wordt gebruikt.

Is het veilig om tijdstempels van productielogboeken in een online converter te plakken?

Een onbewerkte tijdstempel alleen al onthult weinig, maar tijdstempels reizen meestal met context - gebruikers-ID's, tokenclaims, logregels De tijdstempel converter Op Toolz.dev converteert u volledig in uw browser zonder verzonden gegevens, dus het plakken van waarden rechtstreeks uit productielogboeken of JWTS brengt niets bloot.

Hoe converteer ik een Unix-tijdstempel naar een leesbare datum?

Plak het nummer in een converter en lees de UTC- en lokale resultaten, of doe het in code: new Date(ts * 1000).toISOString() In JavaScript, datetime.fromtimestamp(ts, tz=timezone.utc) In Python, date -u -d @ts op Linux. het enige dat je eerst goed moet doen, is of je waarde in seconden of milliseconden ligt - al het andere volgt daaruit.

Hoe krijg ik de huidige UNIX-tijdstempel?

date +%s in een schelp, Math.floor(Date.now() / 1000) In JavaScript, int(time.time()) In Python, SELECT EXTRACT(EPOCH FROM NOW()) in Postgresql. Merk op dat JavaScript de vreemde eend in de bijt is: Date.now() Retourneert milliseconden, dus de divisie is niet optioneel.