Geen upload, 100% lokaal, geen account

Artikel

Unix-tijdstempels en cron-expressies uitgelegd

Een Unix-tijdstempel is gewoon een geheel getal. Een cron-expressie is gewoon vijf velden. Beide komen voortdurend voor in back-endwerk en beide zijn bronnen van voorspelbare verwarring: het ene vanwege tijdzones, het andere vanwege de eenheid.

Wat een Unix-tijdstempel is

Een Unix-tijdstempel telt het aantal seconden dat is verstreken sinds 1970-01-01 00:00:00 UTC, een referentiepunt dat bekend staat als de Unix-epoch. Die definitie heeft twee belangrijke gevolgen. Ten eerste staat de teller in UTC: er is geen tijdzone ingebed in het getal zelf. 1718400000 betekent hetzelfde moment overal ter wereld, ongeacht waar de machine die het opslaat zich bevindt. Ten tweede is de epoch gedefinieerd in seconden, niet in een andere eenheid. Een waarde zoals 1718400000 zijn altijd seconden sinds middernacht 1 januari 1970 UTC, tenzij een systeem of protocol expliciet een andere keuze heeft gemaakt. Tijdstempels zijn tijdzone-vrij by design, wat precies de reden is waarom ze nuttig zijn voor logging, databases en communicatie tussen systemen waar klokken in verschillende regio's naar hetzelfde moment moeten verwijzen zonder dubbelzinnigheid.

Tijdlijn die de Unix-epoch toont op 1970-01-01 00:00:00 UTC links, een huidig tijdstempel in het midden, en de 2038-overloopgrens rechts, gemarkeerd met het maximum van een ondertekend 32-bit geheel getal.

Seconden, milliseconden en het jaar-2038-probleem

Veel moderne runtimes en API's gebruiken milliseconden in plaats van seconden. JavaScript's Date.now() geeft milliseconden terug, dus 1718400000000 is hetzelfde moment als de secondenprecisiewaarde 1718400000. Als je een onbekend tijdstempel ontvangt, geeft de grootte de eenheid aan: een getal van 10 cijfers is vrijwel altijd seconden; een getal van 13 cijfers is vrijwel altijd milliseconden. Het jaar-2038-probleem ontstaat door een andere keuze: een tijdstempel met secondenprecisie opslaan in een ondertekend 32-bit geheel getal. De maximale waarde van een ondertekend 32-bit geheel getal is 2147483647, wat overeenkomt met 2038-01-19 03:14:07 UTC. Na die seconde loopt de teller over naar een groot negatief getal en rolt de datum terug naar 1901 op systemen die de grens niet afhandelen. De oplossing is 64-bit opslag te gebruiken. De meeste huidige besturingssystemen en databases doen dat al, maar ingebedde systemen, netwerkapparaten en oude bestandsformaten die de veldbreedtes tientallen jaren geleden hebben vastgelegd, lopen nog steeds risico.

Epoch omzetten naar een leesbare datum: de tijdzonestap

Een epoch-waarde omzetten naar een leesbare datum vereist twee stappen: haal de UTC-datumcomponenten op uit het gehele getal, pas vervolgens een UTC-offset toe om de lokale tijd te krijgen. Het tijdstempel zelf is UTC. Als je vraagt welke datum 1718325000 vertegenwoordigt, is het juiste antwoord 2024-06-14 om 00:30 in UTC. In New York (UTC-4 in de zomer) valt dezelfde seconde op 2024-06-13 om 20:30 's avonds ervoor: de datum verandert, niet alleen het uur. Dit is de stap die verkeerde resultaten oplevert wanneer hij wordt overgeslagen: een ontwikkelaar logt het ruwe tijdstempel in UTC, een rapportagetool geeft het weer in lokale tijd zonder conversie, en de datum lijkt uren of een volle dag af te wijken. Het tijdstempel-converter-hulpmiddel op Sunasty verwerkt dit expliciet: je voert een epoch-waarde in en het toont de UTC-datum en -tijd naast de eigen lokale datum en tijd van je apparaat, zodat een dagsgrensovergang zoals deze in één oogopslag zichtbaar is. De conversie draait volledig in de browser en niets wat je plakt wordt ergens naartoe gestuurd.

Twee kalenderrasters naast elkaar voor dezelfde epoch-waarde: het UTC-raster markeert een kalenderdag en het raster voor New York (UTC-4) markeert de voorgaande dag, wat laat zien hoe de lokale datum door het tijdsverschil terugvalt.

Cron-syntaxis: vijf velden, bereiken, stappen en lijsten

Een cron-expressie plant terugkerende taken op Unix-achtige systemen. De standaardsyntaxis heeft vijf door spaties gescheiden velden: minuut (0-59), uur (0-23), dag van de maand (1-31), maand (1-12), dag van de week (0-7, waarbij zowel 0 als 7 zondag vertegenwoordigen). Een ster (*) in een veld betekent "elke geldige waarde". De expressie 30 8 * * 1-5 draait om 08:30 van maandag tot en met vrijdag. Bereiken gebruiken een koppelteken: 1-5 dekt de waarden 1, 2, 3, 4, 5. Lijsten gebruiken komma's: 1,15 betekent de 1e en 15e. Stappen gebruiken een schuine streep: */15 in het minutenveld betekent elke 15 minuten (0, 15, 30, 45). Deze combinatoren kunnen samen voorkomen: 0-30/10 betekent 0, 10, 20, 30. Cron heeft geen tijdzoneveld. De daemon leest de klok van de machine waarop hij draait, die is ingesteld op de lokale tijdzone van de server. Als de server UTC gebruikt maar een ontwikkelaar lokale tijd verwacht, viert de planning op het verkeerde klokuur. De praktische regel is cron-planningen te behandelen als server-lokale-tijd-expressies en de tijdzone van de server naast de cron-regel te documenteren.

De tijdstempel-converter lokaal gebruiken

De tijdstempel-converter op Sunasty converteert in beide richtingen: epoch naar leesbare datum en leesbare datum terug naar epoch. Je kunt een waarde met secondenprecisie of een waarde met millisecondenprecisie invoeren; het hulpmiddel detecteert de eenheid aan de hand van de grootte. Het toont het resultaat in UTC en in de eigen lokale tijdzone van je apparaat naast elkaar, samen met de ruwe seconden- en millisecondenwaarden klaar om te kopiëren. Een Nu-knop vult de huidige tijdstempel met één klik in, wat een snelle manier is om de huidige Unix-tijd te controleren zonder een terminal te openen. Er is geen aparte tijdzonekiezer: de lokale kolom weerspiegelt altijd de tijdzone waarop je browser op dat moment is ingesteld. Dit alles draait in de browser. De waarde die je in het veld plakt, wordt gelezen door client-side JavaScript en verlaat het apparaat nooit.

Tools in dit artikel

Veelgestelde vragen

Waarom gebruikt JavaScript milliseconden in plaats van seconden?

JavaScript's Date-object was van het begin af aan ontworpen voor sub-secondeprecisie, en milliseconden geven duizend keer de resolutie van seconden zonder een decimaalteken te vereisen. De afweging is dat waarden groter zijn, wat de reden is dat Date.now() een getal van 13 cijfers produceert terwijl de meeste server-tijdstempels 10 cijfers hebben.

Moet elke server die cron gebruikt op UTC draaien?

Nee, maar servers op UTC draaien is een gangbare praktijk, precies omdat het de dubbelzinnigheid wegneemt. Als een server op UTC staat, betekent een cron-expressie zoals 0 2 * * * om 02:00 UTC en die tijd is het hele jaar stabiel. Op een server in een zone met zomertijd viert dezelfde taak in de zomer op een ander UTC-moment dan in de winter, en bij de klokverzetting kan hij twee keer afvuren of een keer overslaan.

Wat is het veilige opslagtype voor tijdstempels na 2038?

Een ondertekend 64-bit geheel getal slaat tijdstempels met secondenprecisie op tot het jaar 292277026596, wat ver buiten elke praktische zorg valt. De meeste huidige databases slaan tijdstempels standaard op als 64-bit waarden. Als je werkt met een verouderd schema of een binair bestandsformaat dat 32-bit velden gebruikt, is migreren naar 64-bit opslag vóór de 2038-grens de juiste oplossing.