Tijdwaarnemers schrappen schrikkelseconde extra snel uit angst voor storingen

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 42

16-10-2026 • 14:13

42

Lees meer

Het Network Time Protocol

11 aug 2021

Het Network Time Protocol

De wankele basis van kloksynchronisatie

108
Meterconventie stemt voor afschaffing schrikkelseconde
Meterconventie stemt voor afschaffing schrikkelseconde Nieuws van 21 november 2022
VS waarschuwen voor kans op mondiale gps-tijdssynchronisatieproblemen op zondag
VS waarschuwen voor kans op mondiale gps-tijdssynchronisatieproblemen op zondag Nieuws van 23 oktober 2021
Linux-servers crashen door 'schrikkelsecondebug' - update
Linux-servers crashen door 'schrikkelsecondebug' - update Nieuws van 1 juli 2012
2005 duurt een seconde langer
2005 duurt een seconde langer Nieuws van 28 december 2005
Meer producten en artikelen
Internet Wetenschap Tijd

Reacties (42)

-Moderatie-faq
42
42
25
2
0
14
Wijzig sortering

Sorteer op:

Weergave:
GarBaGe 16 oktober 2026 14:18
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.
Reageer
joker1977 @GarBaGe • 16 oktober 2026 14:28
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.
Reageer
skoozie @joker1977 • 16 oktober 2026 14:48
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
Reageer
bbg0 @skoozie • 16 oktober 2026 15:02
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.
Reageer
mat.hi.as @skoozie • 16 oktober 2026 14:51
Omdat het in absolute tijd (bijvoorbeeld UTC) of epoch nog wel vooruit loopt. Dat zou in dit geval niet meer zo zijn.
Reageer
StefanJanssen @skoozie • 16 oktober 2026 15:06
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.
Reageer
Davey400 @skoozie • 16 oktober 2026 15:41
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.
Reageer
SunnieNL @joker1977 • 16 oktober 2026 15:02
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.
Reageer
DaMonkey @SunnieNL • 16 oktober 2026 15:23
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.
Reageer
Memori @DaMonkey • 16 oktober 2026 15:48
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. :)
Reageer
Gwaihir @GarBaGe • 16 oktober 2026 14:26
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).
Reageer
jhnddy @Gwaihir • 16 oktober 2026 14:45
Zo'n groot probleem is een uur niet. Dat doen we al 2x per jaar. Kwestie van een keer overslaan over 1000 jaar.
Reageer
Memori @jhnddy • 16 oktober 2026 15:53
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).
Reageer
jhnddy @GarBaGe • 16 oktober 2026 14:28
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.
Reageer
pagani @GarBaGe • 16 oktober 2026 14:29
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.
Reageer
Rannasha @GarBaGe • 16 oktober 2026 14:31
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.
Reageer
GenomDalar @GarBaGe • 16 oktober 2026 14:34
Ze zullen hier vast nog wel op terug komen als ze weer nieuwe inzichten hebben gekregen.
Reageer
dengregg @GarBaGe • 16 oktober 2026 14:48
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.
Reageer
Blokker_1999
@GarBaGe • 16 oktober 2026 15:04
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.
Reageer
Genosha @GarBaGe • 16 oktober 2026 15:06
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?
Reageer
leuk_he @GarBaGe • 16 oktober 2026 15:41
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.
Reageer
Triblade_8472 16 oktober 2026 14:18
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.
Reageer
joker1977 @Triblade_8472 • 16 oktober 2026 14:31
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.
Reageer
Triblade_8472 @joker1977 • 16 oktober 2026 15:05
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.
Reageer
SPee @Triblade_8472 • 16 oktober 2026 15:51
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.
Reageer
GertMenkel @Triblade_8472 • 16 oktober 2026 14:39
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.
Reageer
LordPan 16 oktober 2026 14:25
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.
Reageer
GertMenkel @LordPan • 16 oktober 2026 14:41
Als GPS en 5G niet meer werken, merkt de mens dat wel degelijk. Een hoop moderne technologie is afhankelijk van preciese tijdsynchronisatie.
Reageer
SunnieNL @GertMenkel • 16 oktober 2026 15:06
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?
Reageer
bytemaster460 @GertMenkel • 16 oktober 2026 14:54
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.
Reageer
michaelkamen 16 oktober 2026 14:21
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.
Reageer
FreezeXJ @michaelkamen • 16 oktober 2026 14:51
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.
Reageer
RePlantIT 16 oktober 2026 14:26
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 :)
Reageer
.oisyn Moderator Devschuur®
16 oktober 2026 14:27
Misschien wordt het gewoon tijd dat we de draaisnelheid van de aarde aan gaan passen zodat hij matcht met onze atoomklokken :Y)
Reageer
adje123 @.oisyn • 16 oktober 2026 14:31
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.
Reageer
michaelvr6 16 oktober 2026 14:33
verschrikkelijk weer zon millenium momentum
Reageer
Master_duck 16 oktober 2026 14:35
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.
Reageer
FreezeXJ @Master_duck • 16 oktober 2026 14:52
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]

Reageer
Mushroomician 16 oktober 2026 14:42
gemiddeld 1,5 jaar voordat een schrikkelseconde nodig is….

Na 15 jaar is dat al 10 sec. uit de maat.

Na 150 jaar zelfs 100. Zijn deze stappen echt irrelevant te noemen?
Reageer
Hansie9999 16 oktober 2026 14:45
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]

Reageer
joker1977 @Hansie9999 • 16 oktober 2026 15:03
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 ?
Reageer

Om te kunnen reageren moet je ingelogd zijn