Gevolgen van schrikkelsecondes?

[Douweegbertje]

Dus, binnenkort komt er: 30 june 2015 23:59:60. Waar zou men op moeten letten?
Ik zelf zou graag rekening houden met wat gevolgen, maar zover ik weet gebruikt bijv. de time functie van PHP de system time middels NTP dus dan heb je daar (denk ik dan) weinig invloed op?

Doen jullie nog iets speciaals omtrent zo'n leap second? Ik heb zelf er eigenlijk nooit last van gehad, maar goed toen draaide ik nog niet veel meuk; nu draai ik zowel *nix, windows server, mysql, mssql, cachings etc.etc..
Op het internet kan ik er eigenlijk niet bijster veel over vinden behalve dat er in het verleden "bugs" waren, en zelfs kernel panic kwam van de leap second.. Echter concrete voorbeelden zie ik niet, noch oplossingen (behalve dat 'uitsmeren van de tijd' door Google)..

[.oisyn]

Ik zie niet in hoe dit in alledaagse systemen problemen kan veroorzaken. Leap seconds bestaan bijvoorbeeld niet in timestamps, en ze zijn doorgaans niet eens op OS niveau geregeld. Uiteindelijk zal NTP je tijd corrigeren, maar dat gebeurt aan de lopende band (de interne klok van je PC is namelijk niet bijzonder precies).

Relevant leesvoer

[ Voor 23% gewijzigd door .oisyn op 13-01-2015 17:12 ]

[Douweegbertje]

Ja nja zo denk ik er ook deels over, maar toen las ik weer over de sql command NOW() wat blijkbaar wél weer :60 of 61 op het einde kan returnen wat uiteindelijk weer invalid is als invoer.
In feite lijkt het me dat een fluctuatie in tijd ook niet zo erg is, echter wel de invalid timestamp wat je "eventueel" zou kunnen krijgen (gezien je argument dat je interne PC klok ook niet precies is, geeft deze altijd wel valid tijden terug).

Ik voorzie zelf ook geen problemen, het is echter dat ik er ook niet te simpel over wil denken en dadelijk iets over het hoofd ga zien

[Onbekend]

Systemen tellen toch gewoon automatisch door?
Na een volgende tijdsynchronisatie blijkt dat ze dan ineens een seconde voor lopen en dat corrigeren ze dan meteen. Dit gaat niet anders dan anders.

[Douweegbertje]

Ja nogmaals is dat irrelevant. Jouw systeem zal immers nooit 23:59:60 aangeven, dat "bestaat" domweg niet. Het is 23:59:00 t/m 23:59:59 en niet :60. Echter zal dit nu toch éénmalig weer even voorkomen, wat wellicht een probleem kan veroorzaken.

[ Voor 24% gewijzigd door Douweegbertje op 13-01-2015 17:54 ]

[NMe]

Douweegbertje schreef op dinsdag 13 januari 2015 @ 17:54:
Ja nogmaals is dat irrelevant. Jouw systeem zal immers nooit 23:59:60 aangeven, dat "bestaat" domweg niet. Het is 23:59:00 t/m 23:59:59 en niet :60. Echter zal dit nu toch éénmalig weer even voorkomen, wat wellicht een probleem kan veroorzaken.

Je systeem zal dat waarschijnlijk niet aangeven, dat telt gewoon door en bij de volgende sync met de NTP-server gaat je klok een seconde achteruit. En zelfs als je systeem dat aangeeft zou dat geen ramp moeten zijn, dat schrikkelsecondes bestaan is geen groot geheim en de belangrijkste software houdt daar vast gewoon rekening mee.

Schrikkelseconden gebeuren trouwens best vaak. De seconde die er dit jaar bij komt is de elfde in 25 jaar tijd. Zie de tabel hier rechts.

[Douweegbertje]

Waarschijnlijk..
Ik ben mij er van bewust dat op die datum heus niet alles om valt, of dat iemand het ooit gaat merken. Mijn vraag is echter; waar zou iemand eventueel op moeten letten; waarom zou het fout gaan? Ik zet het ook in PRG . omdat we zelf enorm veel software draaien, met allerlei connecties naar 3e, integratie via meerdere servers, caching, exchange etc etc.

Mijn 'probleem' deels is dat ik allerlei artikelen vind, die of vertellen dat niemand zich druk moet maken, of dat er allerlei systemen om zijn gevallen. Concreet hoe/wat/waarom kan ik niet echt vinden. Niet voor niets smeert google die éne seconden uit over een langere periode zodat je nooit een leap krijgen.

In 2012 werkte ik hier nog niet, en hadden we ontzettend veel dingen nog niet. In 2 jaar tijd is er veel veranderd. Resultaten uit het verleden bieden geen garantie voor de toekomst

[Megamind]

Als de PC klok niet de 60 gaat aangeven dan hoef je je nergens zorgen om te maken.

SQL NOW() neemt gewoon de datum van de PC en heeft geen eigen rare counter lopen, dus je zal nooit die :60 zien.

[--MeAngry--]

Bij bijvoorbeeld bedrijven als Google is dit een veel groter "issue" omdat zij een boel custom software draaien voor bijvoorbeeld de mailafhandeling. Echter zijn zij ook afhankelijk van NTP etc.

Bij al jouw huis, tuin en keuken programmatuur hoef je je daar echt geen zorgen over te maken. Als jij met NTP een keer je tijd synchroniseert merk je ook niets op, hoogstens dat de sortering op datum/tijd in je MySQL database niet meer helemaal klopt bijvoorbeeld.

Bij Google moet iemand echter ook niet zomaar een handmatige NTP sync draaien op de mailservers daar, want dan kan het behoorlijk fout gaan met de mailafhandeling omdat dit meteen invloed heeft op honderdduizenden gebruikers.

Ze zeggen daar echter ook, hoe goed je jezelf er ook op voorbereid, je komt toch altijd onverwachte zaken tegen omdat er ergens in een stukje code dus bijvoorbeeld assumpties gemaakt worden die een edge case bug trieerden.

[.oisyn]

Douweegbertje schreef op dinsdag 13 januari 2015 @ 17:54:
Ja nogmaals is dat irrelevant. Jouw systeem zal immers nooit 23:59:60 aangeven, dat "bestaat" domweg niet. Het is 23:59:00 t/m 23:59:59 en niet :60. Echter zal dit nu toch éénmalig weer even voorkomen, wat wellicht een probleem kan veroorzaken.

Officieel wel. Maar zoals ik al zei, schrikkelseconden zijn niet op OS-niveau geregeld. Als je bijvoorbeeld kijkt naar de unix timestamp, dan hebben 23:59:59 en 23:59:60 officieel dezelfde timestamp. In realiteit zul je dit niet tegenkomen, omdat het OS gewoon doortelt en geen weet heeft van de schrikkelseconde. Eigenlijk telt de unix timestamp dan ook niet vanaf 1970-1-1 0:00:00 UTC, want elke keer dat er een schrikkelseconde bij of afgaat schuift die begintijd een seconde op. Er zijn er inmiddels 25 geweest, allemaal +1, dus eigenlijk telt de unix timestamp vanaf 1970-1-1 0:00:25 UTC. En de tijd zal in de toekomst wel een keer gecorrigeerd worden.

Maar dat wordt het ook zónder de hele schrikkelseconde-affaire (schrikkelgate? ), want zoals ik al zei, de interne klok van je PC is niet zo heel precies. Als je PC aan een NTP server hangt dan zijn tijdcorrecties aan de orde van de dag, dus je moet sowieso al rekening houden met het feit dat je een keer een timestamp ophaalt die kleiner is dan de timestamp die je een paar seconde geleden op hebt gehaald.

[ Voor 14% gewijzigd door .oisyn op 13-01-2015 23:41 ]

[pedorus]

.oisyn schreef op dinsdag 13 januari 2015 @ 23:35:
[...]

Officieel wel. Maar zoals ik al zei, schrikkelseconden zijn niet op OS-niveau geregeld. Als je bijvoorbeeld kijkt naar de unix timestamp, dan hebben 23:59:59 en 23:59:60 officieel dezelfde timestamp. In realiteit zul je dit niet tegenkomen, omdat het OS gewoon doortelt en geen weet heeft van de schrikkelseconde. Eigenlijk telt de unix timestamp dan ook niet vanaf 1970-1-1 0:00:00 UTC, want elke keer dat er een schrikkelseconde bij of afgaat schuift die begintijd een seconde op. Er zijn er inmiddels 25 geweest, allemaal +1, dus eigenlijk telt de unix timestamp vanaf 1970-1-1 0:00:25 UTC. En de tijd zal in de toekomst wel een keer gecorrigeerd worden.

Maar dat wordt het ook zónder de hele schrikkelseconde-affaire (schrikkelgate? ), want zoals ik al zei, de interne klok van je PC is niet zo heel precies. Als je PC aan een NTP server hangt dan zijn tijdcorrecties aan de orde van de dag, dus je moet sowieso al rekening houden met het feit dat je een keer een timestamp ophaalt die kleiner is dan de timestamp die je een paar seconde geleden op hebt gehaald.

Gek, ik ben niet gewend dat je de boel uit je duim zuigt. Linux doet WEL aan schrikkelseconden, er is een apart veld voor gereserveerd binnen de tijdstructuur. Vorige keer hebben we hier problemen mee gehad omdat we veel java draaien onder hoge load op Linux. Linux zonder fix kan zelfs vastlopen, java onder Linux gaat naar 100% cpu.
http://serverfault.com/qu...shes-during-a-leap-second
http://it.slashdot.org/st...second-bug-causes-crashes
http://blog.cloudera.com/...-to-leap-second-troubles/

De fix was simpel als je het eenmaal wist, de klok instellen (helaas zet dit de klok ietsje terug):

date -s "$(date)"

(of een reboot na vastlopen)
Maar zie daar maar eens achter te komen als je site Reddit of LinkedIn heet en je zojuist enorme problemen hebt door totaal onbekende oorzaak..

De unix timestamp doet per definitie niet aan leap seconds, en telt dus nu straks niet vanaf een ander tijdstip natuurlijk, die seconden horen er namelijk niet in.

NTPd zorgt er niet voor dat de timestamp terug kan gaan over het algemeen, de klok wordt namelijk vertraagd en niet teruggezet. http://serverfault.com/qu...drift-the-clock-backwards

Helaas is er voor zover ik weet geen openbare ntpd / ntp server die aan het google smear algoritme doet, dan had ik gevraagd om dat voor die tijd uit te rollen..

[.oisyn]

pedorus schreef op woensdag 14 januari 2015 @ 01:06:
Linux doet WEL aan schrikkelseconden, er is een apart veld voor gereserveerd binnen de tijdstructuur.

I stand corrected . Ik ging er vanuit van niet, omdat het niet in de unix timestamp voorkomt.

De unix timestamp doet per definitie niet aan leap seconds, en telt dus nu straks niet vanaf een ander tijdstip natuurlijk, die seconden horen er namelijk niet in.

Dat is ook niet wat ik zeg. Wat ik zeg is dat unix timestamp X op dit moment effectief het aantal seconden sinds 1970-1-1 0:00:25 is. Timestamp 0 refereert uiteraard nog altijd naar 1970-1-1 0:00:00

NTPd zorgt er niet voor dat de timestamp terug kan gaan over het algemeen, de klok wordt namelijk vertraagd en niet teruggezet. http://serverfault.com/qu...drift-the-clock-backwards

Dat is 1 specifieke implementatie. Windows keilt gewoon je klok terug.

[ Voor 3% gewijzigd door .oisyn op 14-01-2015 12:14 ]

[emnich]

Als je zelf niet programmeert zal het niet zo veel consequenties hebben. Als je wel programmeert én berekeningen doet met tijden die op de seconde nauwkeurig moeten zijn dan moet je misschien wel even opletten.

[MSalters]

.oisyn schreef op woensdag 14 januari 2015 @ 01:36:
[...]

[NTPd]

Dat is 1 specifieke implementatie. Windows keilt gewoon je klok terug.

W32Time is dan ook geen echte NTP client. Het is een time client die gebruik kan maken van NTP servers, door gebruik te maken van NTP messages. RFC5905 beschrijft NTP, en specificeert een Clock Adjustment Process (paragraaf 13) wat niet geïmplementeerd lijkt te zijn in Windows (dan zou je geen backwards adjustment moeten zien)

[pedorus]

Het lijkt er trouwens op alsof het niet de klok terug zet tenzij het te gek wordt (zoek op clock rate):
http://technet.microsoft.com/en-us/library/cc773263.aspx

Enkel dit vind ik dan weer gek:
Support boundary to configure the Windows Time service for high-accuracy environments

Hoe kun je het zo programmeren dat je maarlieft >2 sec verschil kan krijgen? Sowieso is syncen op de een of andere manier een drama onder windows, het lijkt te vaak mis te gaan en hangt ook af van of je in een domein zit. Allerlei workarounds: http://serverfault.com/qu...hronize-ntp-time-reliably

Je zou denken wat maakt het uit, maar in een serverpark is het wel interessant of a voor b is gebeurd of omgekeerd als er meer dan 1 server bij betrokken is, en mensen doen best vaak meerdere handelingen in 5 seconden.

[ Voor 7% gewijzigd door pedorus op 15-01-2015 00:36 ]

[Fish]

kunnen best hoteldebotel gaan die klokken.

op een vm hen ik voor tijdkritische processen de w32time service uitgezet en de tijd via vmware gelinkt aan pool.ntp.org

Een logging aan de hand van de -stripchart was bleek een stuk stabieler ~.3s afwijking, een stuk beter dan 15~20 secondes

[Resistor]

Ik heb er totaal geen verstand van, maar http://nl.wikipedia.org/wiki/Schrikkelseconde vertelt mij dat dit al veel vaker is voorgekomen. Laatste keer zelfs nog in 2012.

Wat waren toen de problemen?

[doc]

Ja toen waren er problemen en zijn er een flink aantal sites down gegaan (Foursquare, Reddit, LinkedIn e.d.)

Morgenavond is het zover, de meeste software/hardware kan er goed tegen volgens mij, alleen bij een flink aantal Cisco spullen kan het problemen geven. Simpelste oplossing is in de meeste gevallen om tijdelijk NTP even uit te zetten.

Meer info:

http://www.cisco.com/web/....html#~ProductInformation

[ Voor 4% gewijzigd door doc op 29-06-2015 14:40 ]

[Voutloos]

Of zie: http://undeadly.org/cgi?a...rticle&sid=20150628132834

Als je systeem gewoon rustig die seconde mismatch weg werkt is er weinig aan het handje. Het wordt juist lastig als je overal wel hypercorrect 23:59:60 wil zien.

[doc]

Probleem is dat sommige systemen er dus echt stuk op kunnen lopen zoals Cisco Nexus switches met oudere firmware:

http://www.ciscozine.com/leap-second-bug-nxos

Die hebben dan echt een harde power reset nodig om verder te kunnen.

[H!GHGuY]

Er zullen ook dit jaar problemen zijn:
https://lwn.net/Articles/648313/

En natuurlijk systemen die niet voldoende gepatched zijn sinds de vorige ronde die kernel panic's en ander feestgedruis veroorzaakte.

pedorus schreef op woensdag 14 januari 2015 @ 01:06:
[...]
NTPd zorgt er niet voor dat de timestamp terug kan gaan over het algemeen, de klok wordt namelijk vertraagd en niet teruggezet. http://serverfault.com/qu...drift-the-clock-backwards

Niet juist. NTPd heeft ondersteuning voor leap seconds. Als je sync't op een NTP server die leap seconds broadcast, dan zal de server vanaf 24u voor de leap second dit doorgeven aan de clients. Die geven het op hun beurt door aan de kernel en uiteindelijk zorgt die ervoor dat de extra seconde toegevoegd wordt.

NTPd zal wel de klok vertragen als je op een NTP server gesync'd bent die geen leap second broadcasting doet. Die zal dan plots merken dat ie een seconde voorloopt en vervolgens de klok vertragen.

MSalters schreef op woensdag 14 januari 2015 @ 17:39:
[...]
W32Time is dan ook geen echte NTP client. Het is een time client die gebruik kan maken van NTP servers, door gebruik te maken van NTP messages. RFC5905 beschrijft NTP, en specificeert een Clock Adjustment Process (paragraaf 13) wat niet geïmplementeerd lijkt te zijn in Windows (dan zou je geen backwards adjustment moeten zien)

Windows doet eigenlijk het equivalent van "ntpdate <server>" in je crontab file. Geen correctie voor clock drift, niets. Gewoon elke zoveel tijd de klok goed zetten. Krijg je alleszins een mooie zaagtand grafiek uit en mag je niet op vertrouwen als je ook maar iets van goeie tijd-sync wil.

Als je server in een domein zit wordt er wel gesync'd met de domain controller (om replay attacks tegen te gaan, voor zover ik weet), maar verwacht er ook niet veel van.

doc schreef op maandag 29 juni 2015 @ 14:05:
Morgenavond is het zover, de meeste software/hardware kan er goed tegen volgens mij, alleen bij een flink aantal Cisco spullen kan het problemen geven. Simpelste oplossing is in de meeste gevallen om tijdelijk NTP even uit te zetten.

Meer info:

http://www.cisco.com/web/....html#~ProductInformation

Correctie: alleen cisco neemt proactief actie en lijst op voor welke producten er problemen verwacht worden. De rest van de fabrikanten hun spulletjes zijn even vatbaar (veel ervan draaien Linux en hebben dezelfde problematiek). Enkel voor iOS mag je ze aankijken, maar ik neem aan dat ze dat sinds de vorige keer nu wel aangepakt hebben. Nu nog maar hopen dat klanten geupgrade zijn.

Vandaag en morgen verlof, hopelijk is het woensdag niet alle hens aan dek als ik terug kom

[doc]

Correctie: alleen cisco neemt proactief actie en lijst op voor welke producten er problemen verwacht worden. De rest van de fabrikanten hun spulletjes zijn even vatbaar (veel ervan draaien Linux en hebben dezelfde problematiek). Enkel voor iOS mag je ze aankijken, maar ik neem aan dat ze dat sinds de vorige keer nu wel aangepakt hebben. Nu nog maar hopen dat klanten geupgrade zijn.

Vandaag en morgen verlof, hopelijk is het woensdag niet alle hens aan dek als ik terug kom

De meeste andere leveranciers waar ik mee werk hebben ook keurig een overzichtje staan van hun producten en welke vatbaar zijn en een aantal partners in Nederland heeft ook wel wat lijstjes. Zelf doe ik veel met NetApp en die is bijvoorbeeld niet vatbaar (draait op FreeBSD).

Wat lijstjes/meer info:
http://blogs.msdn.com/b/m.../leap-seconds-010815.aspx
How the Windows Time service treats a leap second
https://www.vosko.nl/leap-second
http://www.axians.nl/schrikkelseconde-2/
http://www.axians.nl/blog...t-dit-voor-uw-datacenter/
https://v-reality.info/20...of-june-may-cause-issues/

en mocht je je vervelen tijdens de schrikkelseconde, er is genoeg te doen: http://spendyourleapsecondhere.com

[Bastiaan]

doc schreef op maandag 29 juni 2015 @ 23:15:
[...]

en mocht je je vervelen tijdens de schrikkelseconde, er is genoeg te doen: http://spendyourleapsecondhere.com

Seriously? Inmiddels heb ik al wat werk voor de boeg om mijn secondes weer terug te halen.

[H!GHGuY]

doc schreef op maandag 29 juni 2015 @ 23:15:
[...]
De meeste andere leveranciers waar ik mee werk hebben ook keurig een overzichtje staan van hun producten en welke vatbaar zijn en een aantal partners in Nederland heeft ook wel wat lijstjes. Zelf doe ik veel met NetApp en die is bijvoorbeeld niet vatbaar (draait op FreeBSD).

Dan is het nogal straf om in die zin 'alleen' te zetten.
Ons toestel staat ook in die lijst onder de categorie "vulnerable", maar dat gaat enkel over oude releases. En bij de vorige leap second hebben we welgeteld 2 reports gekregen van zaken die misgingen. Dus de lijst is eerder defensief opgesteld.

[doc]

Klopt, dat is misschien wat straf gesteld, maar bij een hoop leveranciers geld het voornamelijk voor oude releases en is het probleem al een in een hoop releases opgelost, bij de Cisco spullen die ik in het veld tegenkom zit de fix alleen in de allernieuwste releases die vaak nog niet in allerlei support matrixen beschikbaar staan.

Maar goed we gaan het wel zien komende nacht, het zal wel meevallen, maar ongetwijfeld ook her en der een hick-up geven

[.oisyn]

Is de wereld al vergaan?

[H!GHGuY]

Bij ons alvast niet En als je dit leest, werkt het internet ook nog.

Alleen... Griekenland! Die kerels hadden een volle seconde extra om hun geld aan het IMF te storten en ze hebben zelfs dat voor elkaar gekregen...

[ Voor 12% gewijzigd door H!GHGuY op 01-07-2015 13:16 ]

[EddoH]

code:

Clock: inserting leap second 23:59:60 UTC

Onze producten werken nog

Hoorde wel dat de grieken hun lening op 23:59:60 hebben afbetaald. Men zoekt nog naar het geld.

[ge-flopt]

EddoH schreef op woensdag 01 juli 2015 @ 13:17:
Hoorde wel dat de grieken hun lening op 23:59:60 hebben afbetaald. Men zoekt nog naar het geld.

[Damian]

Hier hebben we bij verschillende klanten van ons problemen met hun server. Is niet via remote desktop te benaderen (zwart inlogscherm). Andere klanten gaven weer aan problemen te hebben met applicaties zoals kassa systemen enzo.

Toeval of zien meer mensen dit? Lijkt zich vooralsnog tot Server 2008 (SBS of niet) met exchange te beperken

[Sneezydevil]

Wij hadden maar 1 2008 server die niet meer te bereiken was, maar dat was omdat daar de stroom om 2 uur vannacht uitgevallen was (een hickup had).

En dat zal wel toeval zijn, hele omgeving had even geen stroom.

[markvt]

Damian schreef op woensdag 01 juli 2015 @ 13:55:
Hier hebben we bij verschillende klanten van ons problemen met hun server. Is niet via remote desktop te benaderen (zwart inlogscherm). Andere klanten gaven weer aan problemen te hebben met applicaties zoals kassa systemen enzo.

Toeval of zien meer mensen dit? Lijkt zich vooralsnog tot Server 2008 (SBS of niet) met exchange te beperken

Op 2008 R2 zie ik geen issues, heb geen 2008 servers meer draaien.

Een zwart scherm bij verbinden kan ook 'normale' oorzaken hebben - weleens gezien na een reboot (waarbij updates geïnstalleerd zijn). Vaak kun je met CTRL-ALT-END dan wel weer verder.

[Damian]

markvt schreef op woensdag 01 juli 2015 @ 15:04:
[...]


Op 2008 R2 zie ik geen issues, heb geen 2008 servers meer draaien.

Een zwart scherm bij verbinden kan ook 'normale' oorzaken hebben - weleens gezien na een reboot (waarbij updates geïnstalleerd zijn). Vaak kun je met CTRL-ALT-END dan wel weer verder.

op 8 verschillende machines? Bij 8 verschillende klanten... T'is trouwens SBS 2011 (2008 R2).

[ Voor 3% gewijzigd door Damian op 01-07-2015 15:08 ]

[begintmeta]

Ogenschijnlijk is een cronjob van mij om 23:59:60 uitgevoerd in plaats van op de eerste seconde van de minuut.

[ Voor 8% gewijzigd door begintmeta op 01-07-2015 15:22 ]

[RobIII]

Sneezydevil schreef op woensdag 01 juli 2015 @ 14:10:
Wij hadden maar 1 2008 server die niet meer te bereiken was, maar dat was omdat daar de stroom om 2 uur vannacht uitgevallen was (een hickup had).

En dat zal wel toeval zijn [...]

2:00 vannacht = 0:00UTC
Ik vind 't verdomd stug als 't er niet mee te maken zou hebben.

[ Voor 4% gewijzigd door RobIII op 01-07-2015 16:00 ]

[Sneezydevil]

RobIII schreef op woensdag 01 juli 2015 @ 16:00:
[...]

2:00 vannacht = 0:00UTC
Ik vind 't verdomd stug als 't er niet mee te maken zou hebben.

Was ik mij inderdaad van bewust, was trouwens bij een klant in België. Ik had echter nog niemand anders over powerdips gehoord.

[H!GHGuY]

begintmeta schreef op woensdag 01 juli 2015 @ 15:22:
Ogenschijnlijk is een cronjob van mij om 23:59:60 uitgevoerd in plaats van op de eerste seconde van de minuut.

en dat is die bug die ik hiervoor in het topic al aanhaalde:
H!GHGuY in "Gevolgen van schrikkelsecondes?"

[? ?]

Alweer een desillusie rijker. Ik ging er eigenlijk van uit dat een timestamp altijd vooruit ging, maar zoals je zegt corrigeert het OS adhv een ntp server je tijd natuurlijk en dan kan je wel eens achteruit gaan.

Major flaw, moeten ze toch eens iets aan gaan doen

Ik vind dat elke computer ten allen tijde zijn eigen timestamps zou moeten behouden en elke pc dus een eigen timezone moet krijgen. Who cares of het nu 23:59:60 of 61 of 62 of 23:59:A7 is, teruggaan in de tijd zou de computer moeten kapot maken

[Standeman]

Ik had daarnet een server die uit het niets 100% load had. Maar dat zal wel toeval zijn, want vanochtend deed hij het nog prima..

[H!GHGuY]

? ? schreef op donderdag 02 juli 2015 @ 16:24:
Alweer een desillusie rijker. Ik ging er eigenlijk van uit dat een timestamp altijd vooruit ging, maar zoals je zegt corrigeert het OS adhv een ntp server je tijd natuurlijk en dan kan je wel eens achteruit gaan.

Major flaw, moeten ze toch eens iets aan gaan doen

Ik vind dat elke computer ten allen tijde zijn eigen timestamps zou moeten behouden en elke pc dus een eigen timezone moet krijgen. Who cares of het nu 23:59:60 of 61 of 62 of 23:59:A7 is, teruggaan in de tijd zou de computer moeten kapot maken

Dat bestaat. Het heet CLOCK_MONOTONIC

[RobIII]

? ? schreef op donderdag 02 juli 2015 @ 16:24:
Alweer een desillusie rijker.

Zal ik er een schepje bovenop doen?

Falsehoods programmers believe about time
More falsehoods programmers believe about time; “wisdom of the crowd” edition

[ Voor 22% gewijzigd door RobIII op 02-07-2015 21:49 ]

[? ?]

Wikipedia: International Atomic Time

In the 1970s, it became clear that the clocks participating in TAI were ticking at different rates due to gravitational time dilation, and the combined TAI scale therefore corresponded to an average of the altitudes of the various clocks. Starting from Julian Date 2443144.5 (1 January 1977 00:00:00), corrections were applied to the output of all participating clocks, so that TAI would correspond to proper time at mean sea level (the geoid). Because the clocks had been on average well above sea level, this meant that TAI slowed down, by about 10−12. The former uncorrected time scale continues to be published, under the name EAL (Echelle Atomique Libre, meaning Free Atomic Scale)
...
The instant that the gravitational correction started to be applied serves as the epoch for Barycentric Coordinate Time (TCB), Geocentric Coordinate Time (TCG), and Terrestrial Time (TT). All three of these time scales were defined to read JD 2443144.5003725 (1 January 1977 00:00:32.184) exactly at that instant. (The offset is to provide continuity with the older Ephemeris Time.) TAI was henceforth a realisation of TT, with the equation TT(TAI) = TAI + 32.184 s.[14]

Ik was al verloren bij UTC1 en UTC2 en dan lees ik dat...
Op welke hoogte staan jullie servers?

[.oisyn]

RobIII schreef op donderdag 02 juli 2015 @ 21:48:
[...]

Zal ik er een schepje bovenop doen?

Falsehoods programmers believe about time
More falsehoods programmers believe about time; “wisdom of the crowd” edition

*kuch* .oisyn in "Gevolgen van schrikkelsecondes?"

[RobIII]

.oisyn schreef op donderdag 02 juli 2015 @ 22:08:
[...]


*kuch* .oisyn in "Gevolgen van schrikkelsecondes?"

Niet gezien. My bad. Maar da's dan wel ook een post van voor Christus (in internet tijd, pun intended )

[ Voor 6% gewijzigd door RobIII op 02-07-2015 23:19 ]