Schrikkel seconde Afgeschaft

Met kop en schouders steekt de seconde als SI eenheid boven de andere eenheden uit als het gaat over de nauwkeurigheid die je in je thuis-lab kunt halen. Ik kan een micrometer nog wel meten, dat is slechts een miljoenste van een meter. Een nanovolt en een nanoampère wordt al erg lastig (Blackdog zal daar zijn hand niet voor omdraaien misschien). Bij milligrammen houdt het ook wel op (1 mg= 10-9 kg!). ASML bijvoorbeeld houdt de kritieke onderdelen van zijn steppers ergens binnen een mili-kelvin (10-6in het gareel want anders kunnen ze de nano-meter verplaatsingen niet meer in de hand houden... Probeer zelf maar eens een temperatuur te meten... met een goed thermokoppel ( µV meten) haal je missschien 0.1 K.
Kortom, tijd- of frequentie-metingen kun je thuis dankzij de beschikbaarheid van voor iedereen beschikbare standaards aardig nauwkeurig doen. Denk aan 'tijdzenders' of GPS gekoppelde oscillatoren. In Greenwich (historisch tijd meet instituut) zit overigens buiten de poort een lengte-standaard ingemetseld zodat burgers hun yardstick (of voet) konden controleren.
En nu lees ik op https://www.nu.nl/tech-wetenschap/6413311/schrikkelseconde-wordt-afges… dat de schrikkelseconde verdwijnt omdat de aarde de atoomklokken niet meer volgt qua rotatietijd. Julias Caesar had ook al een reden gevonden om de tijd (lees: kalender) aan te passen aan de aarde en voerde het schrikkeljaar in. En hij had niet eens een atoomklok!
What's the problem? Tja, je auto wordt geflitst en de tijd die erbij staat wijkt, dankzij die software makers die geen rekening hielden met schrikkelsecondes, een seconde af van de 'officiële' tijd... Mijn verweer zou zijn: ik was daar niet eens op die tijd. :) De astronomen worden gepasseerd.
Foutje bij de definitie van de kilo: Gaan we alle recente goudtransacties corrigeren of passen we de geldprijs aan? Misschien alleen interessant voor de time-nuts onder ons (www.leapsecond.com).
De laatste schrikkel-seconde dus.

Ik vind het ook raar, je past de werkelijkheid aan aan je standaard.
Een seconde was ooit gedefinieerd als het zoveelste deel van een dag. Dat was niet nauwkeurig genoeg en daarom hebben ze de cesiumstandaard bedacht. Die is zó nauwkeurig dat er af en toe (ong. eens per jaar) een schrikkelseconde moet worden ingelast. Op het journaal riep een of andere wetenschapper dat dat veel werk met zich meebrengt. Misschien in zijn lab, de rest van de wereld merkt er niks van. Computernetwerken zouden niet goed meer werken zei hij, maar die hangen niet van seconden af, dat is meer minuten of een veelvoud ervan.

Maar goed: Het zal mijn tijd wel duren.

Op donderdag 15 oktober 2026 23:00:58 schreef soldeersmurf:
Bij milligrammen houdt het ook wel op (1 mg= 10-9 kg!).

Voor de goede orde: een milligram is 10-6kg. Misschien bedoelde je een microgram?

Ik geloof dat de cesiumstandaard ook al weer achterhaald is.

Om even terug te komen op die schrikkelseconde, weet je wat nog veel erger is?

Dat de tijd berekening in ALLE Unix system broken is (ook Linux, Solaris etc). Werkt in geen enkel systeem correct.

Dit is het geval: De epoch tijd is de definitie in Unix van het aantal seconden sinds 1 jan 1970 om middernacht. In 32 of 64 bits gedefinieerd om het even. Epoch is per definitie UTC. Epoch 0 => 1970-01-01 00:00:00.

Ok so far so good.

Nu gaan we die epoch waarde even terug rekenen naar de werkelijke tijd, laten we even uitgaan dat we dat in onze tijdzone (EU/Amsterdam) doen vandaag.

In FreeBSD gaat dat met "date -r 0" (0 is epoch waarde) Daar komt dus dit uit:
# date -r 0
Thu Jan 1 01:00:00 CET 1970

Op linux:
# gdate --date='@0'
Thu Jan 1 01:00:00 CET 1970

Dit wordt dus omgerekend naar UTC+0100. Zou kloppen denk je.

Heeft iemand een Linux systeem bij de hand? Wat komt daar nu uit? -> even nu gechecked: Ook Thu Jan 1 01:00:00 CET 1970

Post dat even hier!

Nu komt de grap: Als je dit doet over 2 maanden (in de wintertijd) komt er wat anders uit. Dat is dus broken.

Het probleem is dat de datum/tijd uitgerekend wordt voor de epoch waarde en dan de uitkomst met de HUIDIGE timezone aangepast wordt in plaats van de timezone waar de target tijd in valt.
Zou je dat willen repareren heb je nog een uitdaging omdat je dat iteratief moet doen als je op het randje zit van die overgang.

Tsja, het alternatief is die schrikkelseconde netjes uit te smeren (over een paar minuten/uur/dagen/jaar).

Als ik 10 meter afleg in een seconde rijd ik 36 km/h. Als er net dan een schrikkelseconde valt zou het kunnen lijken of ik 2 seconden over die 10 meter heb gedaan, krijg ik ineens geen boete meer. (in een 15 zone normaal toch een fikse overschrijding, maar op de fiets heb ik daar wel wind mee voor nodig).

Als je die seconde uitsmeert heb je dat probleem niet.

Maar als je probeert te meten hoe lang je CPU over een taakje doet om te kijken of ‘ie 8 of 10 instructies gebruikt… of een andere hele korte tijdspanne. Of je doet iets met dingen als newtonmeters-per-(vierkante)-seconde. Dan is zo’n uitgesmeerde seconde weer onhandig.

Niet dat de fysieke werkelijkheid zich aan dergelijke definitiekwesties gaat aanpassen. Het rekent hooguit lastiger als er voortaan 1.000314159 seconden voorbij moeten zijn gegaan voordat er 1.000000000 Watt verstookt is in een 1.000000000 Ohm weerstand met 1.000000000 Volt er over en 1.000000000 Ampere erdoorheen…. Maar het gaat niet meer of minder warmte opleveren.

Heeft iemand een Linux systeem bij de hand? Wat komt daar nu uit?

Dat valt tegen - hier op een redelijk recente Ubuntu:

$ date -r 0
date: 0: No such file or directory

Maar de opmerking over wintertijd spreek ik (met alle respect) tegen:
tijdzones en al die ellende behoren tot de locale-settings. Ieder Unix-verwant systeem houdt de systeemklok EN de hardwareklok in UTC.

[Bericht gewijzigd door Paulinha_B op (34%)]

Op donderdag 15 oktober 2026 23:45:37 schreef Hensz:
Ik vind het ook raar, je past de werkelijkheid aan aan je standaard.
Een seconde was ooit gedefinieerd als het zoveelste deel van een dag. Dat was niet nauwkeurig genoeg en daarom hebben ze de cesiumstandaard bedacht. Die is zó nauwkeurig dat er af en toe (ong. eens per jaar) een schrikkelseconde moet worden ingelast. Op het journaal riep een of andere wetenschapper dat dat veel werk met zich meebrengt. Misschien in zijn lab, de rest van de wereld merkt er niks van. Computernetwerken zouden niet goed meer werken zei hij, maar die hangen niet van seconden af, dat is meer minuten of een veelvoud ervan.

Maar goed: Het zal mijn tijd wel duren.

[...]
Voor de goede orde: een milligram is 10-6kg. Misschien bedoelde je een microgram?

Dank voor je opmerking. Je hebt gelijk wat betreft die milligram. Kilo is 1000 gr en 1000 mg is een gram, dus 10-6. .

Maar los daarvan, de reden van het afschaffen is dat de IT gedreven maatschappij niet goed kan omgaan met een schrikkelseconde, terwijl schrikkeljaren geen probleem zijn blijkbaar. Schrikkeljaren, elke 4 jaar maar met uitzondering van de eeuw-wisselingen. 2000 (geen schrikkeljaar) was natuurlijk een apart geval: de 'millenium-bug' kon de wereld misschien platleggen.

Als klokken- en Sterrewacht liefhebber vind ik het wel een interessant probleem.

In theorie zou ik hier tegenaan lopen in de firmware die de telescoop richt. De lokale siderische tijd die nodig is om de rechte klimming van een object om te zetten in een uurhoek wordt berekend vanuit UTC en de lengtegraad. In werkelijkheid is ook op een grote telescoop het beeldveld tientallen minuten groot, dus is het niet snel een probleem. 1 tijd minuut komt hier overeen met 15 boogminuten. Ook is de mechanica (helaas) niet zo precies en onze UTC "bron" nu een browser.

Op een meridiaankijker zal men het verloop tussen de hemel en UTC goed kunnen meten, daar zijn ze kort door de bocht voor, maar die van ons staat niet meer op zijn fundering.

De praktische implicaties zijn klein omdat de verschillen tussen bekende tijdsoorten als de internationale atoomtijd TAI, GPS tijd en UTC enkele tientallen seconden zijn en met dit besluit voorlopig ook nog vast liggen.
Dat is groot genoeg om direct op te merken als het er toe doet, en klein genoeg om gewoonlijk geen probleem te zijn.

Op donderdag 15 oktober 2026 23:00:58 schreef soldeersmurf:
[....]
Bij milligrammen houdt het ook wel op (1 mg= 10-9 kg!). ASML bijvoorbeeld houdt de kritieke onderdelen van zijn steppers ergens binnen een mili-kelvin (10-6in het gareel want anders kunnen ze de nano-meter verplaatsingen niet meer in de hand houden...

Dat is onzin! In de scheikunde, biologie en natuurwetenschappen wordt al gesproken over microgrammen (µg), nanogram (ng) en picogram (pg).
Of dat fysiek is te meten is niet van belang; je kan er wel mee werken, alleen al door te extrapoleren of de werkzame stof te mengen met een inerte ballast.
Ik ken bijvoorbeeeld een geneesmiddel dat 290µg aan werkzame stof bevat.

Maar de zin van TS gaat specifiek over het thuislab.

Wie voor de hobby met biochemie bezig is zal beslist in µg / µmol denken, maar ik kom thuis niet lager dan een gram.
Overigens zijn uiterst kleine massa's indien gewenst vrij eenvoudig te meten aan b.v. de resonantiefrequentie van een xtal. Dat zijn gekende technieken die ook wel in een thuislab kunnen.

Op vrijdag 16 oktober 2026 00:15:02 schreef Paulinha_B:
[...]

Dat valt tegen - hier op een redelijk recente Ubuntu:

$ date -r 0
date: 0: No such file or directory

Maar de opmerking over wintertijd spreek ik (met alle respect) tegen:
tijdzones en al die ellende behoren tot de locale-settings. Ieder Unix-verwant systeem houdt de systeemklok EN de hardwareklok in UTC.

Klopt. Maar er zijn nog genoeg machines waar de RTC op local time staat.

Met de zomertijd moeten ze ook gewoon stoppen. Levert ook een hoop ellende op.

Op linux is het een ander commando (met even -u erbij om UTC te krijgen): date -u --date='@0' -> Thu Jan 1 00:00:00 UTC 1970

Het lijkt er op dat ze dit toch ooit gerepareerd hebben, als je dit in de winter draaide was het goed en als je dit nu in de zomertijd draaide kwam er 01:00 uit en werd de DST +1h er domweg bij opgeteld.

Op vrijdag 16 oktober 2026 10:17:38 schreef henri62:
Met de zomertijd moeten ze ook gewoon stoppen. Levert ook een hoop ellende op.

Het is twee maal per jaar de 'ellende' die pakweg een miljoen mensen elke paar dagen, het hele jaar door, hebben omdat ze in ploegendienst werken.

Op donderdag 15 oktober 2026 23:00:58 schreef soldeersmurf:
Een nanovolt en een nanoampère wordt al erg lastig (Blackdog zal daar zijn hand niet voor omdraaien misschien).

Mijn witte leds hebben bij 20V reverse spanning(*) ongeveer 15.5 nA aan reverse current.

Dat is echt niet moeilijk meten. Ik heb dat in 2 minuten voor mekaar, speciaal om te kunnen zeggen: nA meten is niet zo lastig.

Gewoon de multimeter in volt stand als stroommeter gebruiken. Wel een keertje de interne weerstand meten. Mijn meter heeft 10MOhm. Dus ik heb 155mV gemeten met ruim 20V over de led en de meter in serie. 155mV/10MOHm = 15.5nA.

(*) Datasheet zegt dat 5V het max is.... Deze haalt dat "ruim": 20V is kennelijk geen probleem.

Op vrijdag 16 oktober 2026 00:06:49 schreef henri62:
Nu komt de grap: Als je dit doet over 2 maanden (in de wintertijd) komt er wat anders uit. Dat is dus broken.

Nope.


$ uname -a
Linux Koolmees 6.17.0-35-generic #35-Ubuntu SMP PREEMPT_DYNAMIC Tue May 26 13:10:28 UTC 2026 x86_64 GNU/Linux
$ date
Fri Oct 16 14:06:31 CEST 2026
$ date --date='@0'
Thu Jan  1 01:00:00 CET 1970
# change system date
$ date
Thu Nov 12 14:05:56 CET 2026
$ date --date='@0'
Thu Jan  1 01:00:00 CET 1970

Klopt als een bus. UTC is 2 uur verschil met CET in de zomer, 1 uur in de winter. En 1 januarie 1970 valt in de winter

Leuker word het als je naar de zomer van 1970 gaat kijken, want toen had Nederland geen zomertijd:

$ date --date='@13000000' -u
Sun May 31 11:06:40 UTC 1970
$ date --date='@13000000' 
Sun May 31 12:06:40 CET 1970

Whihoe! klopt als een bus!

En je kunt ook verder terug in de tijd:


$ date --date='@-1913000000' -u
Wed May 19 19:06:40 UTC 1909
$ date --date='@-1913000000' 
Wed May 19 19:26:12 AMT 1909

Klopt! Nederland liep in 1909 inderdaad net geen 20 minuten voor op UTC (wat toen nog GMT was.)

in de huidige computer gekoppelde systemen is die seconde wel belangrijk, vooral als die niet ineens overal tegelijk word ingevoerd, oa de beurzen en dergelijke kunnen dan vastlopen. het uurtje wat nu komt als vervanger is wrs goed voor 1000 jaar..

Er zijn inderdaad omgevingen/toepassingen waar erg nauwkeurige tijdsinformatie vereist is. Ik herinner me een groot (veel connectiepunten) en uitgestrekt (veel oppervlakte) netwerk waar de netwerkapparatuur (routers, switches) absoluut dezelfde klok moest hanteren, voor het geval van foutzoeken in de diverse logs: men wou kunnen zien in welke volgorde de diverse evenementen optraden in de diverse componenten. Dan nog heeft men zich daar niet geamuseerd met eigen stratum-0 infrastructuur op te zetten, stratum 2 bleek in de praktijk voldoende nauwkeurig.

Op vrijdag 16 oktober 2026 00:10:58 schreef Lucky Luke:
Tsja, het alternatief is die schrikkelseconde netjes uit te smeren (over een paar minuten/uur/dagen/jaar).

Als ik 10 meter afleg in een seconde rijd ik 36 km/h. Als er net dan een schrikkelseconde valt zou het kunnen lijken of ik 2 seconden over die 10 meter heb gedaan, krijg ik ineens geen boete meer. (in een 15 zone normaal toch een fikse overschrijding, maar op de fiets heb ik daar wel wind mee voor nodig).

Als je die seconde uitsmeert heb je dat probleem niet.

Maar als je probeert te meten hoe lang je CPU over een taakje doet om te kijken of ‘ie 8 of 10 instructies gebruikt… of een andere hele korte tijdspanne. Of je doet iets met dingen als newtonmeters-per-(vierkante)-seconde. Dan is zo’n uitgesmeerde seconde weer onhandig.

Niet dat de fysieke werkelijkheid zich aan dergelijke definitiekwesties gaat aanpassen. Het rekent hooguit lastiger als er voortaan 1.000314159 seconden voorbij moeten zijn gegaan voordat er 1.000000000 Watt verstookt is in een 1.000000000 Ohm weerstand met 1.000000000 Volt er over en 1.000000000 Ampere erdoorheen…. Maar het gaat niet meer of minder warmte opleveren.

Je haalt de absolute tijd en meet tijd wel erg door elkaar. Voor de absolute tijd is zo een schrikkelseconde noodzakelijk voor de gemeten tijd weer totaal niet.

Of je kWh meter nu precies over een dag van 24 uur op 86400 of 86401 seconde uitkomt dat maakt niets uit.

[Bericht gewijzigd door benleentje op (20%)]

Op vrijdag 16 oktober 2026 19:31:10 schreef testman:
het uurtje wat nu komt als vervanger is wrs goed voor 1000 jaar..

Na die duizend jaar wordt het dan niet om 7 uur 's morgens licht, maar pas om 8 uur. Dat is schrikken!

Op vrijdag 16 oktober 2026 21:49:03 schreef Hensz:
[...]
Na die duizend jaar wordt het dan niet om 7 uur 's morgens licht, maar pas om 8 uur. Dat is schrikken!

maar daar hebben dan al 10 generaties langzaam aan kunnen wennen.

Op vrijdag 16 oktober 2026 19:50:59 schreef benleentje:
Of je kWh meter nu precies over een dag van 24 uur op 86400 of 86401 seconde uitkomt dat maakt niets uit.

Maar stel nu dat ik een variabele tijd heb. En dan wil ik "een dag later" hebben.

Dus stel "tijd" is nu 2017-12-31_12:34:56 en je wilt de tijd "een dag later" hebben. Simpel: 86400 seconden later is het: 2018-01-01_12:34:56 ! makkelijk!

Maar wat is nu "een dag later" als we 2016-12-31_12:34:56 beginnen.... Bedoel je dan 2017-01-01_12:34:56 of 2017-01-01_12:34:55 ?

De eerste is "dezelfde tijd een kalenderdag later" en de tweede is "86400 seconden later".

Nu... ik ben van mening dat schrikkelseconden een goed idee zijn en afschaffen is "geboren uit luiheid".

Hetzelfde probleem heb je met "een jaar later". 2025-01-02_12:23:34 en dan een jaar later... 2026-01-02_12:23:34 is 365 dagen... Maar 2024-01-02_12:23:34 naar 2025-01-02_12:23:34 is 366 dagen.

Goed.... deze kan je de komende 3000 jaar gewoon uitrekenen zonder een opzoeken-tabel. Maar het is hetzelfde probleem.

Ik realiseer me nu pas dus dat bij "een jaar later" we meestal bedoelen: "dezelfde kalenderdag/tijd" een jaar later. Dus dan moet "een dag later" ook dezelfde tijd zijn en het verschil in seconden dus 86401 als er een schrikkelseconde is geweest.

Anyway, als je het verschil in seconden tussen twee verschillende data wil weten, kan je voor verrassingen komen te staan als je het niet goed doet. Net als wanneer je denkt dat ieder jaar deelbaar door vier een schrikkeljaar is. Dat is voor het eerst in 2100 niet zo.

Op vrijdag 16 oktober 2026 19:50:59 schreef benleentje:
Je haalt de absolute tijd en meet tijd wel erg door elkaar.

Ik denk dat we het eigenlijk gewoon eens zijn:

Als je een meting over tijd hebt houdt je de tijd bij vanaf ¨t=0¨ op een willekeurige klok-tijd, en zijn je seconden gewoon 1 seconde groot. In de kloktijd kan ondertussen een schrikkelseconde zitten. (Eventueel een uitgesmeerde schrikkelseconde).

Als je die (uitgesmeerde) schrikkelseconde ook in je "meet tijd" zou verwerken gaat het mis.

Toch gaat het wel eens mis, bij reizen tussen tijdzones tegen een bepaald (h)uurtarief moet je opletten. Uiteraard heeft Computerphile of Tom Scott oid daar een filmpje over. (Met een kabelbaantje)

Ik heb het idee van die schikkel seconden altijd al raar gevonden. Het maakt me echt niet uit of deze modderbal een beetje sneller of langzamer rond tolt.

Verder kan ik me wel voorstellen dat die schrikkelsecondes voor een aantal mensen erg lastig zijn. Vooral als je nauwkeurige tijdmetingen wilt doen over lange periode's, b.v. helderheids verschillen van sterren over meerdere jaren (maar of een seconde dan veel uitmaakt?)

Schrikkelseconden (en zomer/wintertijd) zijn lastig als je in software dingen op vaste klok-tijd moet doen (en dus rekening moet houden met schrikkelseconden en zomer/wintertijd), en dingen op vaste intervallen moet doen (die dus niet automatisch synchroon lopen met de kloktijd)

Een voorbeeld is trajectcontrole op snelheid. Als jij a.s. zondag (25 oktober 2026) om 2:59:50CEST het traject (1km)ingaat, en er om 2:00:10 CET weet uitkomt, krijg je dan een boete?] (De controle waar ik ooit betrokken bij was niet, die schakelt rond de wintertijdwissel uit )

Natuurlijk is dit oplosbaar, maar het is iets waar programmeurs fouten mee maken tenzij het in de specificaties uitgewerkt is. Die schrikkelseconde staat niet in de specificaties, dus er gaat heel veel software stuk op het moment dat ie plaatsvind.

maar het is iets waar programmeurs fouten mee maken tenzij het in de specificaties uitgewerkt is

Programmeurs zijn heel goed in staat om fouten te maken, of 'het' nou in de specificaties is uitgewerkt of niet.
In het eerste geval is alleen de eventuele rechtszaak een stuk korter, de schuld krijgen ze sowieso...

En als je nu in de specificaties zet dat de programmeurs fouten moeten maken. Is het dan een overheids project? Of zit dat anders? :)

Op maandag 19 oktober 2026 10:20:38 schreef blurp:
Schrikkelseconden (en zomer/wintertijd) zijn lastig als je in software dingen op vaste klok-tijd moet doen (en dus rekening moet houden met schrikkelseconden en zomer/wintertijd), en dingen op vaste intervallen moet doen (die dus niet automatisch synchroon lopen met de kloktijd)

Google loste dat ooit op door de schrikkelseconde uit te smeren over een uur. Ook een compromis, maar blijkbaar acceptabel.