Home   2026-10-22 19:56:51

←

.Geek - Tijdwaarnemers schrappen schrikkelseconde extra snel uit angst voor storingen

Original article

Het laatste uur van de schrikkelseconde heeft geslagen. Dat is bepaald tijdens de Algemene Conferentie voor Maten en Gewichten in Parijs. Tijdswaarnemers hebben besloten om de schrikkelseconde versneld af te schaffen uit angst voor grote storingen.

Leden van het Internationaal Bureau voor Maten en Gewichten (BIPM) stemden donderdagavond ervoor om de schrikkelseconde versneld af te schaffen. Ze hadden in 2022 al besloten dat die seconde zou sneuvelen, maar dat zou eigenlijk in 2035 gebeuren. Dat vervroegt het BIPM nu naar 20 mei 2027.

In de praktijk betekent dit dat er nooit meer een schrikkelseconde bij komt. De laatste is op 31 december 2016 doorgevoerd. Zo'n schrikkelseconde is nodig om de atoomtijd gelijk te houden aan de rotatie van de aarde. Die atoomtijd wordt op zijn beurt gebruikt om elektronica van tijd te voorzien, zoals telefoons en computers, maar ook servers en satellieten.

Negatieve schrikkelseconde

Er is een goede reden om versneld af te stappen van de schrikkelseconde. De rotatie van de aarde is veranderd, waardoor tijdwaarnemers mogelijk een seconde moeten aftrekken om de atoomklok kloppend te houden. Zo'n negatieve schrikkelseconde is nog nooit ingevoerd. De vrees is dat dit grote problemen zal veroorzaken in kritieke infrastructuur.

Die vrees is niet ongegrond. Schrikkelseconden zorgden in het verleden al voor problemen. Bij zo'n tijdsaanpassing kunnen diensten de synchronisatie met NTP-servers verliezen, met storingen als gevolg. In 2012 gebeurde dat op grote schaal, toen een schrikkelseconde voor een bug in de Linux-kernel zorgde. Die bug haalde servers van Reddit, LinkedIn en andere platforms uit de lucht.

Overstap naar een schrikkeluur

Het BIPM stopt niet helemaal met tijdscorrectie: het introduceert een schrikkeluur. Het verschil tussen de atoomtijd en de astronomische tijd mag dus een uur oplopen voordat er een correctie plaatsvindt.

Dat is een bijzonder ruime marge. De tijd tussen schrikkelsecondes verschilt sterk, maar duurt gemiddeld ruim anderhalf jaar. Het eerste schrikkeluur zal daarom nog duizenden jaren op zich laten wachten.

Atoomklok Physikalisch-Technische Bundesansta. Bron: picture alliance / Getty Images
De atoomklok in de Physikalisch-Technische Bundesanstalt in Duitsland. Bron: picture alliance / Getty Images (Beeld ter illustratie)

Door Daan van Monsjou

Nieuwsredacteur

Feedback • 16-10-2026 14:13 86

16-10-2026 • 14:13

86

Reacties (86)

Tja, de aarde (en de rest van de wereld) zal nooit helemaal exact synchroon lopen met zoiets als een atoomklok.
Dus, ipv het probleem structureel op te lossen, kiezen we ervoor om het probleem voor ons uit te schuiven.
Onvoorstelbaar....
Je kan ook eventueel kleinere stapjes nemen. Misschien een halve seconde... of 100ms?
Op een gegeven moment is de stap zo klein, dat het slechts een miniscule "skew" wordt waar geen enkel systeem problemen mee heeft.
10 stapjes van 100ms is ook 1s.
Hoezo onvoorstelbaar? Vanuit een technologie standpunt is er geen enkele reden om de atoom- en UTC-tijd synchroon te houden met de zonnetijd. Behalve "traditie". Dit is simpelweg een veel eenvoudigere oplossing waarmee we veel problemen voorkomen.

De gedachte dat als je de skew klein genoeg maakt en je daardoor ook geen problemen hebt is leuk, maar met negatieve tijdsverandering ga je terug in de tijd. Het grote probleem is nl. dat je situaties kunt krijgen waar de actie eerder komt dan de trigger voor die actie in het geldende tijdsdomein voor dat systeem.

Afhankelijk van de temporele resolutie van het systeem zou je dan misschien wel in het femto of pico gebied moeten komen van secondes, absurd om correcties zolang te moeten uitsmeren.
Dit hebben wij ieder jaar toch op de laatste zondag van oktober als de wintertijd ingaat? Je kan een telefoon gesprek starten om 02:58 's nachts en het gesprek afbreken 10 minuten later om 02:08... De klok wordt namelijk om 3 uur 's ochtends verzet. Maar omdat we dit zo vaak meemaken houden we er in onze apparaten rekening mee en zorgt dit niet voor problemen
Zomertijd levert inderdaad ook weleens problemen op, maar de onderliggende klok in je computer loopt in die gevallen altijd nog gewoon door (in UTC). Met een schrikkelseconde moet die klok aangepast worden, en daar gaan veel meer processen van over de zeik.

Overigens heeft NTP al een oplossing waarbij de klok nooit gekke sprongen hoeft te maken: je versnelt of vertraagt de klok met een factor X, net zolang totdat je op het target bent uitgekomen. Dat systeem heb je toch al vaak nodig omdat normale computers nooit zo precies zijn als atoomklokken.
Dit hebben wij ieder jaar toch op de laatste zondag van oktober als de wintertijd ingaat?
Wij als mensen wel, de techniek niet. Nou ja, misschien in de auto dan. ;)

Technisch gezien wordt er met een absolute tijd gewerkt en gerekend en wordt in veel gevallen uitgegaan van de UTC standaard, maar er zijn er dus meer.

Wat jij op je klok ziet is die UTC + of - het verschil veroorzaakt door de tijdzone waarin je je begeeft, + een eventuele zomertijd.

Overigens zijn er ook systemen waar nu al geen rekening wordt gehouden met die schrikkelseconde in de meting zelf, maar waarvan de weergave die wel kan worden meegenomen; één daarvan is een hele bekende: de GPS tijd doet niets met schrikkelseconden. Jouw klok in een apparaat 'weet' echter waar je bent en hoe het zit met die schrikkelseconden, en corrigeert de GPS tijd weer naar een tijd die jij als mens graag wilt zien.
Omdat het in absolute tijd (bijvoorbeeld UTC) of epoch nog wel vooruit loopt. Dat zou in dit geval niet meer zo zijn.
Je haalt nu een aantal dingen door elkaar denk ik. Onze tijdzone verschuift maar de tijd veranderd niet. Wanneer datum tijd communicatie is gebeurd dit vrijwel altijd in UTC of met de UTC+timezone. UTC is in het geval van zomer en wintertijd altijd hetzelfde.

Waar het mis gaat is dat met de schrikkelseconde de daadwerkelijke tijd verandert en niet de tijdzone.
Dat lossen we op met timezones:

02:58 CEST (00:58 UTC) is 10 minuten voor 02:08 CET (01:08 UTC), dus dat is geen probleem
Maar nu krijg je alsnog een probleem over paar duizend jaar als er ineens een vol uur verschil is. Als je die schrikkelseconde ergens om 11:56:17 had doorgevoerd was er waarschijnlijk veel minder problemen geweest. Nu hebben ze hem in het verleden waarschijnlijk op een heel uur of minuut gezet, waardoor de kans dat er iets mis gaat veel groter is dan als je hem gewoon ergens op een vaag tijdstip inpland die niemand gebruikt om een job te starten.

Een pc kan er toch ook tegen als die een drift tegenkomt met een timeserver en paar seconde erna weer synced. Dat er in het verleden hele linux systemen in grote getale omvielen hierdoor is echt wonderbaarlijk in mijn ogen.
Als ik het artikel goed lees, is de schrikkelseconde meestal vooruit. Nu hebben we (uitzonderlijk?) een negatieve. En ik denk dat daar het probleem zit.

Alles werkt met triggers (mijn backup loopt elke nacht om 3 uur). Stel dat 3.00.01 ineens terug 3.00.00 wordt, begint mijn backup ineens nog een keer te lopen. En eerlijk, ik weet niet wat mijn script daarmee gaat doen?

Kans dat hij net valt op mijn backup tijd is klein, maar genoeg systeem die wel heel tijd gevoelig zijn, en waar dit voor problemen kan zorgen.

Als we even een "potje" verzamelen, en het pas bij een uur aanpassen, zal er (waarschijnlijk? gezien de negatieve seconde een uitzondering lijkt?) enkel positieve sprongen zijn, en is dit probleem van de baan.

Geeft ons ook een beetje tijd (als hij elke 1.5 jaar komt, en een uur 3600 seconden is, zo een 5000 jaar, afgerond voor de negatieve).

Blijkbaar is er wel al een oplossing, waar tijd niet springt masr sneller of trager loopt (als ik het begrijp wordt 3.00.01 niet 3.00.00, maar loopt hij even wat trager, zodat het 3.00.02 ipv 3.00.03 wordt?), maar mogelijk hebben we binnen 5000 jaar een systeem waarbij we de klok gewoon laten lopen, omdat we niet meer enkel naar aarde tijd moeten kijken (andere planeten).

Dus ja, niet mee rommelen, laten doen, en ineens zomertijd ook afschaffen.
Stel dat 3.00.01 ineens terug 3.00.00 wordt, begint mijn backup ineens nog een keer te lopen. En eerlijk, ik weet niet wat mijn script daarmee gaat doen?
Sowieso moet er de safe-guard zijn dat de backup niet nogmaals draait door naar de last-run tijd te kijken en zien of dit buiten 95% van de intervaltijd valt. Aangezien je een script hebt, kun je nu hiermee dus aan de slag. :)
Die controle zit er in. Met een negatieve schrikkelseconde zijn er echter problemen:

1) De backup loopt nog. Ik denk dat de last run pas wordt geschreven als hij klaar is (met failsafe dat hij niet blijft draaien, en mail met succes/fail, vrij ruim want hij heeft 24 uur).

2) Zelfs als de last run realtime is, ligt deze (bij gewoon 1 seconde terugdraaien) in de toekomst.

Zal wel niet erg zijn voor mijn backup, draait al jaren goed.
Absolute waarde nemen van het resultaat, waardoor je zowel .95 terug als .95 naar voren kijkt. Voor de rest kan je ook kijken of het proces al is opgestart.
Blijft nog steeds een risico.

Er zit inderdaad al een beveiliging op gebaseerd op het proces. Normaal wordt dat na 22 uur geforceerd gestopt (met een mail over fout, 22 genomen al voor de extra speling bij een schrikkeljaar). Maar als het proces al draait stopt hij gewoon en komt er terug een mail met een fout. Dat gaat dus ook problemen met de negatieve schrikkelseconde oplossen, de eerste run blijft gewoon gaan.

Risico met de absolute waarde dat je aangeeft: Het lijkt realistischer dat mijn history tracking ergens fout/corrupt is gegaan, dan dat er een negatieve schrikkelseconde is. Wat dus een mooie oplossing kan lijken, kan andere problemen verstoppen.

En dit is voor mijn backup ... Als we gaan kijken naar iets als real time trading, waar hopen geld aan betere locatie en servers wordt gegeven voor elke fractie van een seconde vertraging weg te nemen, en de trading pcs in het beursgebouw bewust door 70km opgerolde fiber gast voor extra vertraging, is een seconde een eeuwigheid die miljoenen kan kosten.
Script start, checkt of er een vlaggetje staat dat het al loopt. Vlaggetje al aan? Stoppen. Vlaggetje uit? Je bent de eerste vandaag, go! Klaar met de backup? Vlaggetje uit. Iets robuuster dan het hier in een paar woorden staat door ook op het bestaan van het proces zelf te controleren, maar zo kom ik de zomer/wintertijd al een tijdje door.
Misschien de wetenschapers van BPIM eens bellen, dat je de oplossing hebt gevonden. En dan gelijk ook Linus, dat er geen bugs meer in Linux mogen komen.
Je redeneert een beetje vreemd, in mijn ogen:

Je maakt een probleem van iets "over een paar duizend jaar" - alsof we dan nog steeds dezelfde technieken gebruiken met dezelfde tekortkomingen om vervolgens te rapporteren dat een seconde om 11:56:17 wordt doorgevoerd een kleiner probleem is.

Om vervolgens op te merken dat Linux-systemen omvielen juist om wat je voorstelt.

Dus een hypothetisch probleem in duizend jaar is een groter probleem dan een reeel probleem nu ? Snap je hoe raar die redenering is ?
Over duizend jaar hebben we tien keer zomertijd ingevoerd en afgeschaft (elke keer als een ‘grote’ leider opstaat). Door een keertje van zomertijd af te zien lost het probleem zichzelf op
Nee, want we praten hier over utc dat geen zomer en wintertijd kent.
Linux systemen vielen om omdat we die seconde precies op een rond uur eraf trokken waardoor processen (die vrijwel altijd om seconde 0 vallen) omvielen. Moet je nagaan wat er gebeurd als je een vol uur gaat aftrekken op een 0 seconde tijdstip.
Als je rekent dat die schrikkelseconde ongeveer 1 per 2 jaar is, praten we in dit geval over ruwweg 7 millennia.

En dan nog: Als jij je drukmaakt over wat er potentieel gebeurt in 7 millennia dan zou ik zeggen, voeg een commit-comment aan de Linux-kernel aan dat ze het schrikkel-uur om 19:56:23 moeten doen.

En fundamenteler: Wat boeit het als UTC niet meer synchroon loopt met de zonne-tijd? Want juist dát leg je niet uit terwijl dat nou precies de kern van de beslissing is.

Ik zou me in ieder geval drukker om het Y2038 probleem maken dan deze wijziging.
Waarom zou je UTC überhaupt aanpassen tegen die tijd:
Bij een vol uur verschil hoef je UTC niet aan te passen: je kan gewoon alle timezones 1 uur opschuiven tov UTC. (zoals we nu al doen met zomer/wintertijd)
Femto of pico? Dat is te nauwkeurig vrees ik. Je schrikkelttijdsvenster is zeer kort. Binnen databases wordt vaak een nauwkeurigheid gehanteerd van één duizendste van één seconde. Natuurlijk heb je ongelofelijk veel speelruimte als je op Femto / Pico opereert maar heb je eraan gedacht wat je daarvoor moet doen?

Elke computer heeft dan een klok nodig met deze nauwkeurigheid, dat is nu niet het geval. Bovendien is het tijdsvenster van een verandering dusdanig klein dat de kleinste vertraging in het doorvoeren van de verandering voor problemen kan zorgen.

Voor de mensen die een Femtoseconde niet kennen, dat is een biljardste van een seconde.

Leuk, in theorie kun je schrikkelen zonder dat het issues oplevert maar dan moet wel elk apparaat zijn uitgerust met een klok die in deze nauwkeurigheid voorziet. :)
edit:
Theoretisch kan dit betekenen dat een schrikkelevent niet eens wordt opgemerkt omdat de klok van het apparaat waarop het event plaatsvindt te traag is.

[Reactie gewijzigd door bazs2000 op 16 oktober 2026 23:51]

Ik overdreef natuurlijk enigszins met pico- en femto-seconden, maar de manier waarop je de offsets doet hoeft natuurlijk niet op ieder systeem hetzelfde te zijn.

NTP heeft een resolutie die in theorie 200 pico-seconden is. Als jouw OS besluit om de zoveelste LSB's te negeren is dat uiteraard prima. Als jij besluit om je time in micro-seconden te doen dan negeer je die "schrikkel nano-secondes" . Als je wat dieper in tijd duikt dan kom je snel al terecht bij PTP en/of GNSS. Daar is het niet vreemd om de nauwkeurigheid (en zeker de resolutie) in nanosecondes uit te drukken.

Als je dan op zo'n systeem de causaliteit in het tijdsdomein intact wilt houden zul je dus sowieso voor kortere stapjes moeten gaan dan nano-secondes. Vandaar dat ik voor pico-secondes ging.

Het fundamentele probleem blijft echter: Waar in het originele voorbeeld werd gesproken over 1/10e seconde-stapjes en jij naar 1/1000e seconde-stapjes springt, zijn er in de praktijk dus systemen die een veel hogere nauwkeurigheid vereisen.

Als je dan wat dieper naar de systemen kijkt begin je je te realiseren dat er eigenlijk helemaal geen noodzaak is om te synchroniseren aan zonnetijd vanuit het perspectief van de techniek die gehanteerd wordt.

Dus die synchronisatie met zonnetijd is eigenlijk enkel en alleen handig vanuit menselijk perspectief. Laat mensen nou nauwelijks een goed tijdsbesef hebben, dus of we nu op UTC +1 of UTC +2 zitten maakt ons na de transitie bij zomer- en wintertijd al verdomd weinig uit.

Dan is het verschil tussen UTC +1h of UTC +58m43s al helemaal minimaal vanuit het menselijk perspectief.
Het lijkt inderdaad logischer om te corrigeren met stapjes die in de buurt zitten van de normale, telkens d.m.v. NTP gecorrigeerde afwijkingen van apparatuur. De apparatuur kan daar bewezen tegen en voor de maatschappij zijn de correcties zo klein dat deze niets merkt.

Een schrikkeluur is een onzinnig concept; de maatschappij heeft zich over die duizenden jaren simpelweg aangepast en de correctie zou een enorme, nodeloze verstoring opleveren. Dat schrikkeluur is geen afspraak om zoiets ooit te doen, maar om er vooral niet meer over te beginnen totdat het een vol uur is (en voor die tijd realiseert men zich dus vermoedelijk dat er dan nog over beginnen ook niet nuttig is).
Zo'n groot probleem is een uur niet. Dat doen we al 2x per jaar. Kwestie van een keer overslaan over 1000 jaar.
Behalve dat de boeken het straks verkeerd hebben wanneer ze het hebben over de positie van de zon in de zomer of winter. DLS en schikkeljaren terug rekenen is makkelijk. Schikkelseconden niet, daar zul je een naslagtabel voor nodig moeten hebben (om bijv. in het jaar 3000 positie van zon op 12 augustus 2050 te berekenen).
Dat is iets waar je aan gewend bent, wat 2x per jaar gebeurt en heen en weer gaat. Dat kan je niet vergelijken met iets bijzonders wat vele generaties lang niet is gedaan.

Zou nu de wintertijd een uur verschuiven, dan ga je (langzamerhand) op andere tijden naar je werk, sport, etc. Het heeft geen nut dat te doen, want iedereen zal z'n gewoontes vervolgens ook een klokuur willen verschuiven. Het geeft alleen maar spanningen gedurende de overgangsperiode.

(Dit zal een van de redenen zijn waarom de afschaffing van de zomertijd maar niet gebeurt: iedereen wil het wel, maar niemand heeft zin in de 'schok' van een ten opzichte van ingesleten gewoontes veranderde klok. Dus worden we het er maar niet over eens waarop de klok dan vastgezet moet worden.)

[Reactie gewijzigd door Gwaihir op 16 oktober 2026 18:06]

Dit zal een van de redenen zijn waarom de afschaffing van de zomertijd maar niet gebeurt: iedereen wil het wel, maar niemand heeft zin in de 'schok' van een ten opzichte van ingesleten gewoontes veranderde klok. Dus worden we het er maar niet over eens waarop de klok dan vastgezet moet worden.)
De "schok" is juist dat uur verandering van de ene op de andere dag. Dat is tenminste wat ik vooral hoor en lees daarover.

En waar de klok op vastgezet moet worden? Wat dachten we van de gulden middenweg: Gewoon op het halve uur tussen de zomer- en "winter"tijd. Alhoewel dat op zichzelf ongetwijfeld wel weer voor onenigheid en gedoe zal zorgen ...
De apparatuur kan daar bewezen tegen
Tja, niet dus. Er zijn een hoop mensen die er een stuk meer verstand van hebben en er lang over hebben nagedacht, en besloten hebben dat het wél een gevaar oplevert. Dus je hele punt valt in het water.
Oh? Ik kan wel iets meer onderbouwing gebruiken dan een vage bewering van sommigen (zonder duidelijke kennis van zaken) dat het NTP protocol niet daadwerkelijk gebruikt wordt om interne klokken gelijk te zetten. Dat is immers overduidelijk onzin.

Ik durf wel te beweren dat jouw bronnen er juist géén verstand van hebben. Want NTP implementaties vermijden die zo gevreesde sprongen juist op een hele handige manier: kleine correcties worden niet gemaakt door de tijd te verzetten, maar door deze een tijdje te versnellen of vertragen.

@Argantonis Of jij leest mijn punt, in plaats van alleen te blijven ranten? Een verandering van een seconde is in de computerwereld geen kleine correctie. Dat is juist wat problemen veroorzaakt. NTP is véél kleinere klok correcties gewend (maar wel degelijk probleemloos, in beide richtingen).

[Reactie gewijzigd door Gwaihir op 16 oktober 2026 18:39]

Mijn bronnen? Dit is letterlijk waar dit artikel over gaat. Ik zou zeggen volg de link en verdiep je in de redenen.
Versnellen / vertragen zou mijn voorkeur ook hebben. Er zijn meer dan genoeg applicaties die op basis van tijd de volgorde van entries bepalen. Tijdsprongen kunnen dan voor onverwachte resultaten zorgen. Bij versnellen / vertragen blijft de chronologie in stand wat wenselijk is.

Omdat de tijdsprongen op tijdstippen gebeurt waarop doorgaans minder activiteit binnen applicaties / databases gebeurt zijn de problemen minder groot. En wie wereldwijd opereert heeft nog andere mechanismen ingebouwd om de chronologie in stand te houden.

Dat gezegd hebbende, ik vindt het raar dat de schrikkelseconde wordt geschrapt omdat dit leidt tot grotere tijdsprongen en dus nog meer risico.

Ik zou meer heil zien in het toevoegen van een extra gegeven in de tijdsaanduiding.

Stel je zou een letter toevoegen aan de datum/tijd waardoor je dan krijgt 16-10-2026 23:59:59(a). Na het instellen van een schrikkelseconde verander je vervolgens de extra waarde naar bijvoorbeeld 16-10-2026 23:59:59(b).

Binnen logfiles blijft chronologie bewaard doordat er nog steeds kan worden gesorteerd op datum / tijd en omdat datum / tijd een redelijk uniek karakter heeft heb je daardoor veel speelruimte. Voor computers voeg je in feite een extra dimensie toe aan de tijd waardoor je kunt 'schrikkelen' totdat je een ons weegt. En ja, in theorie kan er een rollover plaatsvinden op deze extra dimensie maar gelet op mijn voorbeeld is de kans vrijwel nihil dat er 26 schrikkel-events plaatsvinden binnen één seconde.

Maar het toevoegen vergt veel en betekent een fundamentele wijziging in de wijze waarop wij als mensheid nu met tijd omgaan. Toch zal dit in de toekomst noodzakelijk worden en dat kan maar beter niet te lang vooruit geschoven worden. En al helemaal niet omdat er nu veel meer door AI wordt gedaan, al deze automatische processen hebben baat bij chronologie.
Om het probleem volledig correct op te lossen zou je een dynamische daglengte moeten introduceren. Maar waarom zouden we? Voor extreem accurate metingen hebben we een atoomklok beschikbaar, en als je iets wilt meten in een tijdsduur van dagen is die ~1 ms verschil per dag niet relevant. 24:00:00 is accuraat genoeg voor een daglengte.
Genoeg kritieke systemen die al problemen gaan hebben als er 1 (of erger nog -1) ms verzet wordt. Ofwel je mist dan data/computes of je hebt ze dubbel.
Tja, de aarde (en de rest van de wereld) zal nooit helemaal exact synchroon lopen met zoiets als een atoomklok.
Dus, ipv het probleem structureel op te lossen, kiezen we ervoor om het probleem voor ons uit te schuiven.
Onvoorstelbaar....
Het probleem is niet echt structureel op te lossen omdat de rotatieperiode van de Aarde niet constant is. Deze neemt, gezien op langere tijdschalen, geleidelijk toe (dagen worden steeds langer). Maar dit is gebeurt niet op een constant tempo. En bepaalde onvoorspelbare gebeurtenissen, zoals aardbevingen, kunnen de rotatie van de Aarde beinvloeden.
Je kan ook eventueel kleinere stapjes nemen. Misschien een halve seconde... of 100ms?
Op een gegeven moment is de stap zo klein, dat het slechts een miniscule "skew" wordt waar geen enkel systeem problemen mee heeft.
10 stapjes van 100ms is ook 1s.
Het probleem is het maken van het stapje, niet hoe groot die is. Een sprong van 1s is niet wezenlijk problematischer dan een sprong van 100ms. Maar iedere keer dat zo'n correctie moet plaatsvinden bestaat de kans op problemen. Dus minder vaak is beter. En als de klok een paar seconden afwijkt van de rotatie van de Aarde is dat niet iets dat iemand ooit gaat merken. Zelfs enkele minuten is geen probleem. En dat betekent dat je al weer een eeuw verder bent voordat er iets moet gebeuren. Tegen die tijd werken klokken misschien wel heel anders of zijn we begonnen aan kolonisatie van de ruimte en hebben we een tijdsmeting die onafhankelijk is van de Aarde.
Afhankelijk van de toepassing van de klok merk je afwijkingen met de rotatie van de aarde zeker wel.

GPS of andere sateliet navigatie doet echt niets nuttigs meer voor positie bepaling als de tijd van de GPS satelieten met x seconden zou afwijken.

Uiteindelijk heb je denk ik net zoals je nu al hebt meerdere tijdstandaarden nodig. En moet je er een kiezen afhankelijk van je toepassing.

GPS tijd wijkt ook af van UTC tijd. Converteren van de ene tijd naar de andere is ook mogelijk.
Ze zullen hier vast nog wel op terug komen als ze weer nieuwe inzichten hebben gekregen.
Ik denk dat het gewoon gemakkelijker is om een apparte atoomtijd te gebruiken, en deze los te koppelen van de rotatie van de aarde.

Enkel voor de correcte weergave heb je een kleine correctie nodig, maar aangezien veel klokken intern al op gmt staan en niet op de lokale tijdzone, gebeurd die omrekening toch al.
Je kan het ook omkeren. Ik vond de uitvinding van de schrikkelseconde net onvoorstelbaar. Want wat proberen we hier eigenlijk te compenseren?

Vroeger werd een dag aanzien als "het is middag als de zon op zijn hoogste punt staat". Met de introductie van de klok hebben we daarvan gemaakt dat middag om 12:00 zou vallen. Maar dan kreeg je weer dat elk dorp zijn eigen tijd had. Toen kwamen de spoorwegen, en die hebben voor een meer universele tijd gezorgd omdat tijdsomzettingen anders onmogelijke tabellen nodig hadden net omdat elke locatie zijn eigen tijd had. Maar vanaf dat moment is de klok daarmee ook irrelevant geworden aan ons dagritme. Middag op de klok is niet middag voor de zon.

En dan heb je ineens de moderne mens. Die wil niet eens meer dat zijn dagindeling gelijk loopt met een zonnedag. Nee, we willen werken als het donker is en thuis zijn om van de zon te kunnen genieten. Vandaar dat zovele mensen blijven vasthouden aan dat zomeruur.

Mochten we de rotatiesnelheid van de aarde in realtime kunnen meten en met een resolutie die hoog genoeg is, dan zou je klokken vandaag de dag nog kunnen afstemmen op die rotatiesnelheid, en dan zou je een zonnedag ook weer exact 24h kunnen maken. Maar dat lukt ons niet. Alle andere oplossingen zijn geknoei waarbij ik de vraag moet stellen wat je wenst te bereiken.

En ja, we duwen het probleem nu voor ons uit. Kan dat kwaad? De kans is zeer groot dat dat schrikkeluur er ook nooit zal komen. Zelfs als we op dat moment nog altijd dezelfde klok gebruiken als vandaag, zelfs als we ook nog altijd dezelfde conventie hebben rondom tijd en die schrikkelseconde gaan we daartegen al lang in een andere tijdzone zitten. Want zonsopgang om 11u in de ochtend in de winter is ook niet iets waar de meeste mensen op zitten te wachten.
Maar... Tijd is een concept van de mens en alleen de mens. Alle andere levende wezens gebruiken geen tijd, hebben dat concept niet en leven op de stand van de zon en maan en jaargetijden. "We" schuiven het inderdaad voor ons uit, maar wat is daar het probleem van?
We hebben verschruivingen van zomer naar wintertijd van een uur, waarom zou je je dan druk maken over een seconde? Als je ergens die exacte offset tussen zonnetijd en UTC nodig heb houd je dat toch gewooon bij, kan dan elke dat geupdate worden.
Ik neem aan dat over 1000 jaar alle hardware en software een stuk verder geëvolueerd is en dit probleem een stuk makkelijker te tackelen. Als we dan nog bestaan en niet terug de steentijd ingeschoten zijn.
Dus we kiezen eieren voor het geld...

Ipv degelijk alle te bouwen, gaan we een workaround toepassen door iets simpelweg niet meer te laten gebeuren.

Wat nou als de aarde weer opeens langzamer of sneller gaat draaien, dan moeten we alsnog een correctie toepassen. Beter alles te behouden en de software beter te maken! Naar mijn mening iig.
Hoezo "moeten" we een correctie toepassen ? Dat hoeft in beginsel niet. Niets verplicht je om de gehanteerde systeemtijd in het gareel te houden met de zonne-tijd.

En die systeemtijd kun je voor weergave-purposes prima terugrekenen naar zonnetijd met een eenvoudige offset en bijbehorende tabel.
Omdat je tijd andere simpelweg niet meer matched met de dag die je fysiek ervaart. Dat is juist het hele punt, als de aarde spontaan veranderd van snelheid, kan de weergegeven tijd niet meer kloppen met de dag die je leeft. Daarom zou de software de klok altijd moeten kunnen volgen, ongeacht of die vooruit of achteruit gezet wordt, zonder stuk te gaan.
Maar met 1 seconde per jaar, hoe groot is dat verschil dan? In 60 jaar is dat verschil maar één minuut! Pas over 1574 jaar, zouden we 1 uur achterlopen tov het jaar 0. Voordat de tijd niet meer matched met de dag-die-je-ervaart, is de mensheid alweer uitgestorven.
Het artikel meld:
De rotatie van de aarde is veranderd
Dus om die reden. Dat kan vaker gebeuren, sneller of juist trager. Wie weet! Als je de software gewoon geschikt maakt, is dat een kopzorg minder, niet?
Die "software gewoon geschikt maken" is juist een hele grote kopzorg: Falsehoods programmers believe about time
Een van de moeilijkste dingen is tijd, tijdzones en deze goed krijgen.

Bij mijn vorige project hadden we vaak problemen met de zomer-wintertijdwissel (en vv). Pas na meerdere jaren ging het eindelijk een keer foutloos. In mijn huidige project kreeg ik de vraag "waarom gebruik je NOW() AT TIMEZONE x in je query?". Nou, omdat - als ik dat niet doe - er een twee uur tijdverschil in zit en mijn query niet werkt. Nu heb je onderliggend een tijdindicatie (UTC) waar je geen rekening houdt met tijdzones en die gewoon eenduidig werkt: tijd gaat met +1 vooruit, 60 seconden in een minuut, 60 minuten in een uur, 24 uur in een dag.
Nu wil je daaraan een schrikkelseconde verschil aan toevoegen. Dus op een complex systeem dat nu al regelmatig niet goed gaat, wil je extra complexiteit aan de basis toevoegen, zodat je soms Ts+1 en Ts+1-1 kunt doen, die dezelfde tijd representeren, maar niet gelijk zijn. En dat voor een minimaal verschil over meerdere jaren. 8)7

De beste manier om een kopzorg minder te krijgen, is daarvan gewoon zeggen: nee, laat maar, gaan we niet doen. Laat ze maar over 1000 jaar een beslissing nemen of ze een keer een extra uur meepakken in die zomer-wintertijdwissel.
De tijd die jij hanteert zit in afwijking ordes van grootte naast de "echte zonnetijd" omdat je in een tijdzone zit van 1 uur.

Het verschil tussen Amsterdam en Arnhem is al veel groter dan decennia van het negeren van de schrikkelseconde. Dat is dus aantoonbaar een redenering die niet klopt :)
De correctie hebben we alsnog nodig, alleen nu op andere plekken. Een jaar is geen echt jaar en een dag is geen echte dag, en precisiesoftware gaat kapot als je ervan uitgaat dat de klok correct is terwijl hij niet klopt. Dat is ook het punt van de schrikkelseconde. Registreer hem of niet, de schrikkelseconde verandert nog steeds de preciese opstelling van hemellichamen vergeleken met de klok op aarde.

Als we gewoon de software beter konden maken, konden we iedere maand de schrikkeltijd exact bijstellen. Eerlijk gezegd lijkt dat me de betere oplossing, de problemen rondom dit concept ontstonden omdat de schrikkelseconde zo weinig voorkomt dat de code lange tijd ongetest gaat. Doe veel regelmatiger een correctie en de software explodeert ook niet wanneer die correctie nodig is.

Om met het gebrek aan correctie om te gaan, moeten we alsnog de software gaan ombouwen. De software kan er niet meer van uitgaan dat de tijd zoals door de meest preciese systemen op aarde berekend ook daadwerkelijk binnen een seconde klopt. Uitgaan dat de klok correct is, maakt rekenen een stuk makkelijker. Nu zal de nodige correctie elders in de software moeten gebeuren. Het probleem is niet opgelost, slechts verplaatst.
die seconde was toch geen mens die dat merkte, zo een seconde meer mogen slapen...

Nu nog de onnodige wisseling tussen zomer/wintertijd afschaffen (persoonlijke voorkeur voor wintertijd), en het zou nog eens een stuk makkelijker worden.
Als GPS en 5G niet meer werken, merkt de mens dat wel degelijk. Een hoop moderne technologie is afhankelijk van preciese tijdsynchronisatie.
Die werken alleen niet meer als de correctie ergens fout gaat. Als we gewoon niet corrigeren en laten doorlopen valt GPS en 5G ook niet uit.
Maar moderne technology is ook gebouwd om drift weer te synchroniseren. Een seconde vooruit of achteruit is normale drift in mijn ogen. Daar moet alles gewoon mee om kunnen gaan. Dat systemen door de war raken als ze syncen en een seconde terug moeten in de tijd, dat is echt waanzin. Hoe doen ze dat als ze echt een keer een hardware drift hebben?
Het BIPM stopt niet helemaal met tijdscorrectie: het introduceert een schrikkeluur.
Ik las gisteren dat hier nog geen besluit over was genomen. Het kon ook nog een schrikkelminuut worden.
Het effect is hetzelfde: de eerstkomende 50 jaar gaan we niet bijstellen. Tegen die tijd hebben we vast betere inzichten, en kunnen we altijd nog terugkomen op wat er nu besloten is.
Pffff, dat ze dan ineens gewoon overal naar "stardate" overschakelen hééé :)

lopen we meteen sycroon met alle toekomstige andere beschavingen :)

Wat ze vooral zouden moeten doen is dat gedrocht van de "winter/zomer" tijd afschaffen , dat is nu eens 100% nutteloos en super irritant (zeker als je jonge kinderen en/of dieren hebt)

heb het concept "daylight savings time" nooit begrepen (ook vroeger niet) , daar is toch nog geen seconde ooit "daylight" mee "gesaved" ???? doe dan gewoon in de wintermaanden je winkel en/of school dat je wenst een uur vroeger open ???? ipv godverdomme de hele klok te herdraaien !!!!!

Was altijd leuk in mijn "World of Warcraft 40man raid day's" , tof met 15+ nationaliteiten in je guild, en dan nog eens die leukers van Engeland die dan soms zelfs een tijdje op 2 uur verschil zaten. de dag dat het uur weer veranderde wist je gewoon dat de raid weer niet op tijd ging beginnen :)

[Reactie gewijzigd door Hansie9999 op 16 oktober 2026 14:47]

Het moet toch niet heel moeilijk zijn om even te internetten voor een uitleg van het hoe en waarom van zomer- en wintertijd ?

Je hoeft het er niet mee eens te zijn om te begrijpen wat de voor- en nadelen zijn, toch ?
Welk voordeel is er dan dat je ook niet kan bekomen door gewoon bepaalde maanden van het jaar je werk/school/winkel andere openingsuren te geven ?

Als de boer gewoon een uur vroeger op staat , dan heeft hij exact evenveel seconden daglicht hoor.

Net zoals dat het ook geen zak verschil maakt in het verkeer, als je het vroeger ligt maakt, dan zit de avondspits meer in het donker, en ben redelijk zeker dat er meer ongelukken gebeuren door de mensen die hun kinderen een uur vroeger uit hun bed moeten halen en half doodvallen van de extra stress en dan iemand omver rijden ipv dat er minder ongevallen zouden gebeuren omdat de spits smorgens meer licht heeft ? (en opnieuw, dat kan je ook gewoon oplossen door de school in de wintermaanden op andere uren te beginnen, daarvoor moet je niet IEDEREEN irriteren door het uur te veranderen)

genoeg nadelen, en mij moet nog het eerste (niet zever) voordeel verteld worden
Met alle respect, maar zodra er voor- en nadelen van zomertijd worden besproken is de discussie wel een beetje klaar als je begint over "de school/winkel/werk een uurtje later te beginnen". Ik bedoel dat is toch exact hetzelfde als zomertijd, behalve dan dat het een stuk onduidelijkheid toevoegt en een spreiding die voor de meeste mensen met (sociale) verplichtingen volstrekt onhandig is.

Ik denk dat je de voordelen van zomertijd niet moet zoeken in verkeersveiligheid, maar vooral in het voordeel dat je in de zomer 's avonds langer daglicht hebt, wat een voordeel is voor recreatie in de buitenlucht.

Of dat voordeel groter is dan mogelijke nadelen laat ik in de midden. Het is duidelijk dat er voordelen en nadelen zijn, dat jij enkel de nadelen ziet en de voordelen niet (wilt zien) is verder niet zo relevant, lijkt me ?
Het laatste uur van de schrikkelseconde heeft geslagen.

Briljante zin!
Om vervolgens te lezen dat er een uur bij komt. Zo zie je maar; tijd heelt alle wonden :)
Misschien wordt het gewoon tijd dat we de draaisnelheid van de aarde aan gaan passen zodat hij matcht met onze atoomklokken :Y)
Ik denk dat het makkelijker en verstandiger is om de aarde 60 seconden niet te laten draaien. Dan hoeven we de komende 60x de schrikkelseconde niet toe te passen.
Langer dan 60 seconden per keer zou ik onderstandig vinden om verschillende redenen.

Ik zie de Nobel-prijs wel verschijnen.
Daar is China al mee bezig: Hun Drieklovendam is zó groot dat het invloed heeft op de draaiing van de aarde. Minimaal, maar wel meer dan 0.01ms.

Als dat niet lukt, dan stel ik voor om snooze-knop op die atoomklok te zetten.
mercury slopen en een Dyson bol van bouwen. Beetje onvoorspelbaar qua effect op de rotatie :) maar impact heeft het zeker.
Of 16 miljoen Drieklovendammen bouwen.. Klein drama qua ecologie, maar verder probleem opgelost...
Dus als we langzamer gaan draaien worden we ook langzaam dichterbij de zon getrokken. Noemt iets met de opwarming van de aarde.....
Behalve dat die afstand de temperatuur niet bepaald. Ja, wellicht een biljarste graad ofzo ;)
De afstand tussen de aarde en zon is nooit gelijk door het jaar, omdat de aarde in een ellips draait. Het verschil in afstand is daarom binnen een jaar al een paar miljoen kilometer dichter / verder weg van de zon.
verschrikkelijk weer zon millenium momentum
hebben ze daar niet UTC en UT1 tijd voor? maar Uh wat is er mis met een zonnen wijzer? die loopt altijd bij. ja niet zo nauwkeurig maar goed genoeg voor de 24uurs klok, uren en minuten. en ja de zon schijnt altijd ook in de nacht.
Omdat jij dan een andere tijd hebt dan ik, en da's lastig als je de trein wilt nemen. Vroeger (een eeuw geleden zeg maar) hadden we dat, en was er Utrechtse tijd, en Amsterdamse tijd, en zo nog wat. Vrij irritant als je dan de trein van kwart over 9 pakt, en aankomt om... kwart over 9 (of kwart over 10, afhankelijk van de kant).

[Reactie gewijzigd door FreezeXJ op 16 oktober 2026 14:53]


Om te kunnen reageren moet je ingelogd zijn