Tele2-netwerk geeft verkeerde tijd en datum door aan klanten

Het mobiele netwerk van Tele2 geeft de verkeerde datum door aan zijn klanten. De meldingen stromen binnen dat het op de telefoons van gebruikers namelijk al 1 januari is in plaats van 31 december.

Het resultaat van de verkeerde datumdoorgave heeft verschillende uitwerkingen. Zo kunnen applicaties vastlopen en bepaalde geplande bewerkingen, zoals back-ups maken, uitgevoerd worden op momenten waarop dit mogelijk niet uitkomt. Aan de praktische zijde zijn er meldingen van Tele2-klanten van wie de wekkers niet afgingen, doordat deze waren ingesteld om juist op zaterdag 31 december af te gaan.

Er komen veel meldingen binnen van Android-toestellen die getroffen worden en een enkeling die ook op Windows 10 Mobile last heeft van het euvel. Meldingen van iPhone-gebruikers die de verkeerde datum zien, zijn er niet.

Het probleem doet zich volgens DroidApp ook voor bij de internetverbindingen en televisieaansluitingen van Tele2, maar onduidelijk is of dit op deze gebieden ook daadwerkelijk tot problemen leidt. Tele2 zou bezig zijn met het oplossen van het probleem. Intussen kunnen gebruikers op hun smartphones de automatische tijdssynchronisatie uitzetten en handmatig de juiste tijd en datum instellen.

Reacties (181)

[low-res]

Lijkt op een NTP issue.

Zijn er tweakers die dit al hebben onderzocht? Het is mij niet duidelijk welke NTP servers tele2 gebruikt...

[robert_paats]

Een telecom bedrijf heeft meestal zijn eigen NTP Servers draaien die meerdere klok bronnen gebruiken, denk dan aan bijvoorbeeld het volgende :
- Een eigen referentie klok (Erg duur lijkt me sterk dat tele2 er een heeft)
- GPS Klok referentie (Of andere satelliet navigatie referentie Glonas/Galileo)
- DCF77 langegolf klok uit Duitsland, gratis uit de lucht te halen.
- NTP Klok bronnen van het internet

Het mooiste is dus je eigen referentie maar als alternatief kan je de Satelliet navigatie systemen gebruiken en DCF77 maar dan ben je wel afhankelijk van een derde partij. Mocht er iemand met een jammer de radio signalen verstoren in de buurt van je NTP server dan kan je een Geo redundante locatie gebruiken om dat weg te mitigeren.

Als nood oplossing kan je internet NTP servers gebruiken als je niets beters heb maar dat doe je bij voorkeur niet.

Je zou bijvoorbeeld een Meinberg klok kunnen gebruiken maar er zijn de nodige leveranciers van dit soort NTP servers.

[Reactie gewijzigd door robert_paats op 23 juli 2024 16:23]

[Gillie]

De referentie klok bied enkele een stabiele kloktik (frequentie) welke stabiel blijft gedurende een hold-over tijd. Een frequentie vertelt geen tijd. Het is relatief, zie het als een liniaal zonder cijfers. Je moet de 'streepjes' tellen om te weten hoeveel afstand je hebt gemeten. Dat is hetzelfde met tijd, nergens in het universum kan je lezen welke 'datum en tijd' het exact is.

Referentie klokken, zijn er in verschillende varianten, van de duurste variant met Cesium (Stratum 1/G.811 nauwkeurigheid). Tot Rubidium (Stratum 2/G.812) en Quartz (Stratum 3/G.813) frequentiebronnen zijn stabiel genoeg om respectievelijk weken (Rb) en 1-3 dagen (SiO2) niet gesynchroniseerd met een 'master klok' door te draaien en nog steeds acceptabele toleranties.
Een Quartz NTP server, kan middels synchronisatie met GNSS, relatief eenvoudig Stratum 1 'nabootsen'.

Rubidium is voor normaal bedrijf betaalbaar. Zeker met synchronisatie van een of meerdere GNSS systemen (GPS/Galileo/Glonas etc.).

Stratum 1 nauwkeurigheid, is bijvoorbeeld de omtrek van de aarde meten tot op cm's nauwkeurigheid. En heb je af en toe een aanpassing nodig, de zogenaamde 'leapseconds'.
Leapseconds e.d. worden door software uitgevoerd. De leapsecond, word altijd in UTC 0:00:00 uitgevoerd. In NL is dat op 1-1-2017, 0:59:59 -> 0:59:60 -> 1:00:00.
Waarschijnlijk is er iets misgegaan met interpretatie van het invoeren van de leapsecond (31-12-2016 0:59:59 --> 01-01-2017 0:59:60 01-01-2017 1:00:00).

[Reactie gewijzigd door Gillie op 23 juli 2024 16:23]

[Sharkoon]

wat moet ik bij duurder, duurste voorstellen in euros?

[Gillie]

Het is (te) lang geleden(>10jr.) dat ik dergelijke apparatuur heb ik 'gekocht'.

Cesium niet mee bezig gehouden, niet te betalen voor onze toepassing. En zwaar overkill.

Rubidium, klok modules waren toen rond de 10k€*. Quartz modules. 4-5k€*. Let wel dit waren de modules, daarbij komt nog GNSS modules, Antenne. Rack chassis, voeding etc. Dit is meer voor het 'echte' werk met 10.000 nodes en kwaliteit hoog moet zijn. Dit is totaal andere apparatuur dan een standalone NTP server.
_{* Diep gegraven uit het hoofd, kan er nu totaal naast zitten.}

Wat ik wel heb kunnen opzoeken, de standalone NTP servers. Toentertijd Symmetricom SyncServer S200 geplaatst voor synchronisatie van servers en zijn opvolger gevonden.
Een simpele 1U NTP server inclusief GNSS antenne zijn er al vanaf 4k (i.e. Microsemi SyncServer S600). Beetje redundantie, koop/laat je er 3 synchroniseren met GNSS systeem voor de juiste datum/tijd. En voor de kwaliteit bewaking (drift/wander) van de tijd, als 'peer' elkaar in de gaten houden. Eventueel aangevuld met Rubidium of oven Quartz module voor een betere (en langere) hold-over mode mocht GNSS problematisch worden/zijn. Maar GPS icm. Galileo (elkaars backup) zou dat geen probleem meer hoeven zijn.

[Ayporos]

Ik vraag me af hoe relevant dat is voor een provider als een Tele2.

Het zou mij nl. echt een worst boeien als de TV of mijn mobiel een of twee seconden achter/voor loopt, en mijn horloge staat gelijk met de klok op het werk die aangeeft wanneer de dienst/pauze begint/eindigt omdat dat de relevante tijd is, ongeacht of die nou een of een paar minuten voor of achter loopt.

Ik snap vanuit 'professioneel' oogpunt dat het nodig is dat je je tijd correct doorgeeft aan de apparaten van je klanten, maar tenzij je op de aandelenmarkt handelt of bankier bent of zo kan ik de noodzaak van zulke precisie niet echt inzien... en al helemaal gezien je in zulke gevallen zeer zeker niet afgaat van de tijd die Tele2 doorstuurt.

tl;dr: ik ben al lang blij dat mijn horloge degelijk genoeg is dat ik hem niet elke maand bij hoef te stellen.

[Gillie]

Het gaat niet om 'tijd'. Wel om juiste en tijdige uitwisseling van encryptiesleutels. En allerhande andere synchronisatie methoden.

[Ayporos]

Kun je dat verder uitleggen?

Als jij een klant zijn apparaat een tijd doorgeeft die 1 of 2 seconden afwijkt (en jou servers hanteren diezelfde afwijkende tijd) dan vind de uitwisseling van encryptiesleutels ed. toch ook gewoon 1 of 2 seconden verschoven plaats? Daar merk je volgens mij als zijnde Tele2 en/of klant helemaal niks van... ?

[Gillie]

Encryptie en certificaten: I.e. encryptie/certificaat afhankelijk van tijdstempel.
Als de tijd van de apparatuur afwijkt, betekend dat de data niet ontsleuteld kan worden. Ook omschakelen naar nieuw sleutelpaar kan problemen geven. Dit hoort tegelijkertijd, aan beiden zijden, van de verbinding te gebeuren. Deze Tele2 storing is daar een perfect voorbeeld van.

Synchronisatie methoden: Herstellen van de frequentie. Als de zender en ontvanger een kleine afwijking hebben in de grondfrequentie. Er gaat dan informatie verloren omdat er bits worden overgeslagen of bits eerder aankomen. O.a. blokken in beeld.

[Ayporos]

Ja ik snap je hele punt prima hoor maar als de tijdafwijking aan BEIDEN kanten hetzelfde is (immers synct het eindapparaat met je server) dan levert dat voor encryptie en certificering tussen deze betreffende twee apparaten (client en server) toch geen problemen op?...

Je hebt mijn vraag helaas nog niet beantwoord.

[Gillie]

Certificaten verlopen exact, dus als je twee seconden achterloopt, betekend dat een certificaat 'ongeldig' is gedurende twee seconden.

[Ayporos]

Wederom, is dat een certificaat tussen tele2 en de klant(machine) or met een derde partij?.. indien het een derde betreft snap ik dat het een probleem kan zijn maar als het een certificaat is enkel tussen tele2 en de klant dan maakt het geen drol uit dat beiden (dezelfde) verkeerde tijd hanteren.

[rvt1]

DCF77 lijkt me geheel niet Die klok bronnen kunnen je heel gemakkelijk zelf nadoen en met een beetje zender dicht bij een gebouw die op die tijd leunt de tijd 'verzetten'. DCF77 is volgens mij ook niet geheel precies vanwege de hardware en modulatie technieken die DCF77 gebruikt.

Als Tele2 iets gebruikt is het GPS en hebben ze zelf lopen te klooien vanwege die 1 seconde extra die we vandaag hebben, lijkt me een laatste momentje probleem zo van oops, dat waren we vergeten en laten we even op onze eigen klok verder, en die stond net even verkeerd.....

[erikmeuk3]

Daar kun je de mist mee in gaan.
Die seconde komt in Nederland een uur later vanwege de tijdzone.
Dus pas om 00:59:60 in Nederlandse tijd.

[Kees]

De internet NTP servers zijn zo onbetrouwbaar niet. Die lopen in ieder geval niet ineens een dag voor of achter. Sowieso wil je minimaal 5 bronnen gebruiken zodat je foutieve bronnen uit kan zetten.

[r2504]

Zelfs één bron is al voldoende... zolang je maar aangeeft dat het maximale verschil niet meer dan een seconde of twee mag bedragen. Dergelijke verschillen kunnen normaal nooit gebeuren en zouden dan ook niet zomaar worden overgenomen.

[trogdor]

Zodra je dan, om wat voor reden dan ook, een poosje geen contact kan krijgen met die bron, en je klok daarna 3 seconden voor of achter loopt dan synchroniseert hij in het geheel niet meer. Lijkt me niet zo'n goed dee dus.

[r2504]

Stel het dan in op een minuut... in ieder geval lijkt een manuele ingreep me dan beter dan de ellende die men nu heeft !

Het absurde is echter dat Microsoft 48 uur (al gaat het hier nog over een W2008) hiervoor aangeeft... https://blogs.msdn.micros...maxposnegphasecorrection/

[leuk_he]

Tijdzone verkeerd. Niet de milliseconden, maar de uren staan fout.

[Anoniem: 826615]

kijk daar zijn ze echt vooruitstrevend

[Pietervs]

We zijn inmiddels 12 uur verder, en Tele2 heeft dit NOG niet gefixt?

Begin me af te vragen of het probleem niet wat structureler is dan een tijdservertje die het niet doet...

[Rolfie]

Vergeet niet dat afhankelijk wat de impact is, je niet zomaar even systemen een dag terug kan zetten in tijd. Databases werken vaak met timestamps voor transacties. Terug zetten, zou beteken dat er al transacties in de toekomst hebben plaat gevonden, of dat timestamps 2 keer kunnen voorkomen.

Impact van afwijkende grote tijdsfouten kunnen major zijn.

[Kees]

Timestamps voor transacties moeten wel twee keer voor kunnen komen lijkt mij, anders kunnen ze maar 86400 transacties op een dag doen

Verder is het werken met timestamps ook niet echt (meer) aan te bevelen, je kan beter de datum+tijd opslaan. Maar ook dan heb je transacties die in de toekomst liggen. Het lijkt mij dat elke database daar wel mee overweg moet kunnen, anders hebben ze elke keer bij de DST-transitie problemen.

De reden dat het nog niet gefixt is lijkt mij eerder dat de meeste devices de tijd niet zo vaak synchroniseren. Windows doet het bijvoorbeeld maar eens per week. Dan moet je dus handmatig de tijd syncen of goedzetten voordat je van de foutieve tijd af bent.

[rvt1]

Dan ga je er even vanuit dat je maar een transactie per seconde kan doen, en dat is natuurlijk niet waar.

Waar Rolfie denk ik op doelt is dat als je twee DB server's wilt synchroniseren dat je dat met technieken van timestamp kan doen, en als de twee server's verschillende tijd hebben dan kun je in de problemen komen, of dat met Tele2 zo is is maar de vraag natuurlijk.

[MrFax]

Nee zelfs in chat logs heb je vaak ook nog miliseconden en denk dat het in software achter de schermen nog veel verder gaat dan dat.

[Reactie gewijzigd door MrFax op 23 juli 2024 16:23]

[OddesE]

De meeste programmeer omgevingen bieden API's voor de tijd die op nano seconde precies (kunnen) werken... echter in de praktijk is dat 'nep' want het vereist stevige hardware die vrijwel niemand heeft. Milliseconde is zelfs vaak al niet heel betrouwbaar. De meeste clocks hebben een resolutie tussen de 3 en 25 ms. Dat wil zeggen dat als je gewoon in een loop die tijd meet je eerst heel vaak een bepaalde waarde krijgt en dat die dan 'ineens' verspringt naar een waarde zo'n 10 ms verder.

[MrFax]

Maar accuracy is bij computertaken toch niet zo'n groot probleem? Je hebt toch *sowieso* al zo'n 120ms delay als je een bericht vanuit hier naar Australie(berekening snelheid van het licht) stuurt, dus het kan sowieso nooit precies kloppen.

[MicGlou]

Een timestamp kan uiteraard ook met tienden, honderdsten en duizendsten werken.

Vervelende is dat er op Win10 Mobile nergens een handmatige sync met de windowsservers is te vinden, alleen met die van je provider. Je kan dan wel handmatig tijd en datum goed instellen maar bepaalde apps zoals de agenda nemen dat dan niet over... dat heeft ook weer invloed op de alarmen.

[Rolfie]

Timestamps voor transacties moeten wel twee keer voor kunnen komen lijkt mij, anders kunnen ze maar 86400 transacties op een dag doen

Timestamps met volg nummer. Replicatie tijden, jobs die oude informatie van de dag er voor moeten verwijderen of Datawarehousing allemaal dingen die met tijd werken.
Bijvoorbeeld een garbage collection of een job moet maar 1 keer per uur lopen. En hij heeft al gelopen in de toekomst, dus zal de komende 24 uur niet meer lopen. Allemaal problemen die met tijds aanpassingen naar voren kunnen komen.
Hoe groot de problemen zijn, is natuurlijk sterk afhankelijk van wat het doet.

Het lijkt mij dat elke database daar wel mee overweg moet kunnen, anders hebben ze elke keer bij de DST-transitie problemen.

GMT tijd formaat wordt daarom veel gebruikt, eventueel met tijdzone er bij vermelden. En menig script wat geprogrammeerd wordt, loopt huist op dit soort DST aanpassingen fout. Vaak genoeg gezien (ook uit eigen ervaring).

De reden dat het nog niet gefixt is lijkt mij eerder dat de meeste devices de tijd niet zo vaak synchroniseren. Windows doet het bijvoorbeeld maar eens per week. Dan moet je dus handmatig de tijd syncen of goedzetten voordat je van de foutieve tijd af bent.

NTP wordt vaak wel vaker update. Maar Window domain controllers zal standaard een grote afwijking niet willen doorvoeren. De kans dat er dan een foute tijd source gebruikt wordt is te groot.
Windows in een domain doet de check trouwens standaard om de 3600 seconden, non domain members inderdaad 1 keer per week.

Maar een goede applicatie kan er ook mee overweg, maar om even een tijd in een enterprise omgeving aanpassen, daar moet je even goed overnadenken wat de impact kan zijn.

[kakanox]

volgens die theorie:86400000 keer. de meeste database systemen werken met yyyy-mm-dd hh:mm:ss.xxx

probleem is echter meer dat een laatate record zoeken ineens niet meer resulteert in het laatste record, maar in het laatste record van voor de correctie.

[Reactie gewijzigd door kakanox op 23 juli 2024 16:23]

[sebastienbo]

Windows 10 doet het ook bij elke windows start-up indien de klok meer dan 16 uur fout staat.

https://www.raymond.cc/bl...clock-on-windows-startup/

pc herstarten kan het probleem dus al oplossen voor windows 10 gebruikers (en dat is nodig als je nog gebruik wil maken van https ....

[SunnieNL]

Je zou in ieder geval naar je eindklanten al de goede tijd kunnen doorsturen. De interne overige systemen kunnen daarna nog wel.

[supersnathan94]

denk je? Ik weet dat iPhones kompleet over de zeik gaan als de tijd op het toestel niet overeenkomt met de tijd van je provider als je zo stom bent geweest om de sim pincode aan te laten. Gerepareerde toestellen worden door stroom onderbreking vaak gereset naar UNIX time 0 (1 jan 1970) en dan accepteert de provider de kaart niet. Een afwijking van enkele minuten is nog acceptabel, maar ik weet niet of een dag dat ook nog is.

[erikmeuk3]

Dan kun je nog beter een nieuw adres voor een goed lopende NTP server aan maken.
Dan kunnen de klanten met de hand omschakelen.
Dan de oude na een tijdje offline halen.

[Oekiejoekie]

Het gevolg is denk ik ingrijpender als de oorzaak. Als ze domweg de datum "opeens" goedzetten, leidt dat tot rare dingen. Zoals een telefoontje van 3 minuten, wat opeens -23:57 uur geduurd heeft. En alllerlei andere dingen waar het billing-systeem van over de zeik raakt. Ja. Ik snap dus wel waarom ze niet "gewoon even de tijd goed zetten" als ik kijk hoe breed de impact is.

[FrankHe]

Bij de overgang van het jaar 1999 naar 2000 hebben ze het heel simpel opgelost. Iedereen mocht op 31 december een dag gratis bellen. Op 1 januari gewoon alle tellers op 0 gezet en de voorgaande dag niet in rekening gebracht. Daar hebben ze toen in een marketingcampagne nog een mooie draai aan gegeven met 'gratis bellen'. De werkelijke reden was dat het te duur was om uit te zoeken hoe het jaar 2000 (jaar 00) probleem werkelijk op te lossen. Misschien moeten ze bij Tele2 vandaag maar even hetzelfde truukje uithalen.

[Oekiejoekie]

Euh ja, maar dan heb je het over gratis bellen. Iets wat tele2 niet veel kost en waar het waarschijnlijk goedkoper is om je verlies op te nemen.

16 jaar later hebben we bewaarplicht van telecomgegevens. Mogen die een dag kwijt zijn ? Ik zie ook dat interactieve tv-boxen betrokken zijn. Zijn alle gehuurde films dan gratis ? Zullen de rechthebbenden leuk vinden. Of als je vanavond de oudejaarsconference opneemt om die te kijken als je thuis komt, en de opnames blijken niet te bestaan ?

[Pietervs]

Mogen die een dag kwijt zijn
Die gegevens gaan niet verloren, ze worden alleen niet gefactureerd. Het feit dat de klok een dag teruggezet wordt wil niet zeggen dat daarmee de database ook geleegd wordt

Of als je vanavond de oudejaarsconference opneemt om die te kijken als je thuis komt, en de opnames blijken niet te bestaan ?
Precies het risico dat mensen nu lopen: dingen die voor vandaag ingeprogrammeerd zijn worden niet uitgevoerd. Als simpelste voorbeeld wordt in het artikel al genoemd, dat bij veel mensen vanmorgen de wekker niet afging...

Los daarvan: ik snap dat het terugzetten van de tijd op servers gevolgen heeft. Maar nu wentelt Tele2 het probleem af op de klanten (je doet maar een dagje zonder onze tijdswaarneming), zonder dat er bericht is geweest naar de klanten toe: die moeten het uit de pers vernemen. En er lijkt ook geen oplossing te komen. Tenminste: geen andere oplossing dan "we doen net of het vandaag 1 januari is, en morgen weer"

[FrankHe]

Ik schrijf nergens dat er data wordt weggegooid, er wordt alleen niets doorbelast / gefactureerd op deze ene dag waarop zich een uitzonderlijke situatie voordoet. Dat heet overmacht. De verkeersgegevens zullen vast wel ergens worden opgeslagen dan mag de opsporingsdienst lekker zelf even een scriptje schijven dat de tijden corrigeerd.

Bij mijn weten worden films per stuk afgerekend en niet per minuut. Als die wegens een technische storingen een dag niet werken dan is er nog geen man / vrouw over boord. Morgen weer een dag.

[micla]

Ik had er ook last van, maar het gewoon laten gaan. omstreeks 16:00 uur was het voor mij oplost en gaf m'n tel weer de juiste datum aan.

[CAPSLOCK2000]

Zijn er geen navigatiesystemen in de problemen gekomen? Om GPS te gebruiken heb je volgens mij een nauwkeurige klok nodig. Ik weet niet genoeg van GPS, wellicht dat apparatuur alleen naar de relatieve tijdverschillen kijkt en niet naar de absolute tijd. Als de klok verkeerd staat gaat je plaatsbepaling dan niet ook de mist in?

Een betrouwbare manier om klokken over langere tijd synchroon te houden is een nog niet opgelost probleem waar we een hoop baat van kunnen hebben. Idealiter wil je een apparaat na dertig jaar uit het magazijn halen en dat de klok dan gewoon direct goed staat.
Een praktische reden om dat te willen is beveiliging op lange termijn. Denk aan de beveiliging van atoombunkers of IoT-apparatuur, niks zo lullig als voordeur die na 10 jaar niet meer open wil omdat het certificaat verlopen is.

Nog al wat encryptiesystemen werken met sleutels/handtekeningen die maar een bepaalde tijd geldig zijn. Een SSL-certificaat is bijvoorbeeld typisch maar drie jaar geldig. Om te controleren of het nog klopt moet je dus wel een betrouwbare klok hebben. Deze situatie is overigens dubbel lastig. Na dertig jaar zijn de root-certificaten van zo'n apparaat waarschijnlijk hopeloos verouderd. Die zou je dan via internet willen updaten, maar hoe ga je dat veilig doen? Het probleem begon er nou net mee dat we zonder betrouwbare klok en/of eeuwig geldende certificaten geen basis van vertrouwen hebben.

Wellicht kunnen we iets bedenken met gedaisychainde-certificaten en ondertekende timestamps maar ik denk dat er nog wel een paar PhD's doorgedraaid worden voor we een goede oplossing hebben.

[pe1dnn]

GPS heeft een eigen klok, los van die provider. De GPS klok is ook een doorlopende klok, dus elke seconde een seconde erbij. Bij invoegen van een schrikkelseconde loopt de teller dus 1 seconde verkeerd. Stel je seconde teller is 1483228798 op 23:59:58 dan is er een berekening die 1483228798 seconden optelt bij een beginstand (epoch, in dit geval 1-1-1970 GMT), volgende seconde is 1483228799 dus 23:59:59; nu de schikkelseconde 1483228800 is 23:59:60 en 1483228801 is 0:00:00. Als je de oude beginstand zou gebruiken zou je op 00:00:01 komen, de GPS klok loopt opeens een seconde voor. Geen punt, de GPS zend namelijk ook een correctie uit en die verhogen ze gewoon met 1 seconde (dus 1 seconde extra in mindering brengen). Dus de klok blijft stoïcijns doorlopen, gewoon doortellen in hetzelfde nauwkeurige ritme.

Bij GPS is de absolute tijd onbelangrijk en vooral voor de gebruiker. Wat belangrijk is dat is dat in alle satellieten de tijd exact gelijk loopt en dat je GPS ontvanger exact synchroniseert met 1 van die satellieten. Dan kun je namelijk meten hoe lang de signalen van de andere satellieten onderweg zijn geweest. Doordat de klokken in al die GPS satellieten gelijk lopen weet je dat alle signalen op exact hetzelfde moment verzonden zijn. Ontvang je dus een andere eerder dan is die iets dichterbij en ontvang je het later dan is de andere satelliet iets verder weg want het signaal is iets langer onderweg). En je weet ook precies waar die satellieten zich boven de aarde bevinden want dat zenden ze ook uit (de almanac). Dus we weet waar die dingen hangen en wat de tijdsverschillen zijn op jouw locatie. De rest is een beetje rekenen.

Doordat is allemaal super nauwkeurig moet kun je in je GPS ontvanger geen andere klok gebruiken dan die van de satelliet. Maar het blijft een relatieve tijd want het is je alleen te doen om tijdsverschillen. Als je eenmaal je locatie weet kun je ook terug rekenen waar de tijd in GPS op staat en met de uitgezonden correctie kun je er ook een absolute tijd van maken.

Belangrijk voor elke klok is dat hij vooruit gaat. Ik heb ergens gelezen dat bij Google met de klok niet door laat lopen van 59 naar 60 maar de klok een minuscule fractie langzamer laat lopen, zo verliest de klok heel langzaam die extra seconde in zonder rare kloktijd sprongen en zonder rare berekening met een minuut met 61 seconden waar de meeste toepassingen niet echt raad mee weten. Uiteraard loopt de klok dan een tijd iets langer voor, maar dat is veel beter dan rare tijd sprongen. Het mag gerust een paar dagen duren en de afwijking is dan minimaal.

Hoe dan ook, de klok die je GPS gebruikt is zeker niet je systeem klok, hooguit kun je je systeem klok aanpassen met behulp van de GPS informatie. Maar in elk netwerk van systemen is de systeem klok uitermate belangrijk en mag een klok alleen vooruit en nooit terug. En bij GPS moet zelfs elke tik altijd even lang duren en pas je bij sprong alleen het correctie getal aan.

[DrVic]

Met GPS is het probleem ook dat de tijd langzamer gaat in die satelieten (relativiteitstheorie), daar moet men dus voor corrigeren

[pe1dnn]

Zolang de tijd maar eenparig progressief is, is dat geen probleem en die satellieten vliegen gelukkig allemaal even snel, anders wordt het wel een hoofdpijn berekening (voor zover dat het al niet is). De klokken zullen ook nooit 100% exact gelijk lopen dus er zal ook nog wel een correctie per satelliet zijn om op een gemeenschappelijke tijd uit te komen. De timing van de ontvangen signalen zullen ook Dopplereffecten hebben waardoor de symbol rate van elke satelliet net wat anders is en ook nog varieert.

Al met al geen eenvoudige techniek, de eerste GPS ontvangers voor burgers, Navstar kasten voor de scheepvaart, waren ook behoorlijke dozen en pas pakweg 10 jaar later hadden ze het zo klein dat het in een handheld paste. Wat dat aangaat een wonder dat het nu de gewoonste zaak is dat het als klein onderdeel in elke telefoon zit.

[jongetje]

Huh, wat heeft GPS nu met het tele2 netwerk te maken?

[polopolo150]

Hier op de iPhone geen last van. Misschien wel op andere toestellen?

Of heb ik gewoon geluk?

[Chris.nl]

Op Android toestellen met de instelling op "Netwerk tijd gebruiken" is het in ieder geval raak.
Nu begrijp ik waarschijnlijk ook waarom m'n wekker niet afging, hij stond ingesteld op zaterdag ochtend 9.30 maar volgens m'n OP3 was het zondag.

[CaptJackSparrow]

Ik vertrouw niet op het netwerk voor de juiste tijd omdat ik altijd het gevoel had dat het voor die netwerken geen prioritijd was en ik meen dat ik ook jaren geleden al eens kon constateren dat die netwerktijd redelijk fors kon afwijken van de écht juiste tijd. Is nu wellicht beter, op vandaag na dus.

Een van de appjes die ik dan ook altijd op een nieuw device installeer is ClockSync.

https://play.google.com/s...?id=ru.org.amip.ClockSync

Dat checkt de tijd met NTP servers waar men zich alleen met de juiste tijd bezig houdt. Weinig kans dat die collectief de fout in gaan.

Vanwege Android permissierestricties (wat geclaimd wordt een ontwerpfout te zijn) kan die helaas alleen op geroote devices automatisch syncen maar het 'handmatig' moeten doen met handige hulp van de app is een kleine moeite en geeft je meteen een eigen controlemoment.

[Reactie gewijzigd door CaptJackSparrow op 23 juli 2024 16:23]

[Anoniem: 855731]

Het lijkt me stug dat de netwerktijd afwijkt. Het wordt nl. ook gebruikt voor de synchronisatie tussen alle netwerknodes. Als er iets niets goed is, kan je helemaal niets meer. Tegenwoordig hangen alle netwerkelementen aan een NTP server.

[C0rnelis]

Stug wellicht, maar niet onmogelijk. Het komt vaker voor bij allerlei netwerken, niet alleen in Nederland/bij Tele2. Ik vink zelf altijd "Netwerk tijd gebruiken" uit op elk toestel waarop het mogelijk is om niet de dupe te zijn van een "oops", eg http://nos.nl/op3/artikel...oeg-wakker-door-fout.html. Terugkomend op NTP, blijkbaar gebruiken er ook een aantal telecomnetwerken https://en.wikipedia.org/wiki/NITZ - al staat Tele2 voor Nederland daar niet tussen.

[Dorank]

Of Tele2 nu wel of niet NITZ gebruikt (het is schijnbaar een GSM feature, Tele2 is 4G only (waar je mag hopen dat ze iets beters geimplementeerd hebben)), volgens de wikipagina:

or NITZ, the "accuracy of the time information is in the order of minutes".
..
Because the NITZ delivery is not usually periodic but dependent on the handset crossing radio network boundaries, these handsets can be displaying incorrect time for many hours or even days before a NITZ update arrives and corrects them.

Tijd uit het mobiele netwerk bij KPN en Vodafoon kan net zo bagger zijn.

[mae-t.net]

4G only, afhankelijk van waar op het netwerk die tijd wordt geserveerd.

[Dorank]

Ik gebruik al jaren niet meer de tijd uit het GSM netwerk nadat ik tot de conclusie kwam dat KPN er een paar minuten naast zat (makkelijk aantoonbar met bv het hierboven genoemde clocksync (of elke andere willekeurige ntp client)).

Voor sync tussen onderdelen in een netwerk maak het echt niet uit wat de echte tijd is, als iedereen in het netwerk maar ongeveer gelijk loopt. Het enige wat van belang is de clock frequentie drift, absolute tijd boeit niet.

[thefox154]

Inderdaad netwerk tijd uit. Kom geregeld in het buitenland en dan zien we weer hoe verwend we hier in Nederland zijn. Onlangs in Ghana een netwerk dat doorgeeft dat het 3 uur snachts is terwijl je net aan je avond eten begint. In kroatie en mongolie dezelfde ervaringen gehad. Sindsdien staat het altijd uit is een echte no go als je veel reist.

[PPie]

Vanwege Android permissierestricties (wat geclaimd wordt een ontwerpfout te zijn)

Is zeker geen ontwerpfout voor het mogen zetten van de tijd.
Als iedere app de tijd mag zetten ben je gevoelig voor replay attacks.

[Xubby]

Waarom je telefoon synchroniseren? De mijne loopt minder dan een minuut per maand fout, zonder bijzetten of synchroniseren.
En al helemaal geen dag fout.

[jsnl]

Dat checkt de tijd met NTP servers waar men zich alleen met de juiste tijd bezig houdt. Weinig kans dat die collectief de fout in gaan.

Klopt, server die afwijkt wordt, minimaal tijdelijk, "eruit geschopt", zit in het NTP protocol verweven.

[DdeM]

Het kan zijn dat in jou geval de service van Apple gebruikt wordt. Is iig op mijn Windows 10M wel het geval, die tijd komt via Microsoft en niet van de provider.

[SED]

Interessant.. war zit die setting op W10Mobile?
Ik ken alleen de language and time setting en daar kun je alleen auto of manueel kiezen.

Interessant dat er wel een technotip is;
https://msdn.microsoft.co...re/mt157030(v=vs.85).aspx


Interessant, dat lijkt dus alleen te werken als er geen GSM beschikbaa ris:
https://msdn.microsoft.co...re/mt157027(v=vs.85).aspx

[Reactie gewijzigd door SED op 23 juli 2024 16:23]

[DdeM]

Het is die auto setting, die instellingen komen van de server van Microsoft. Dat moet ook, want de 2 step authenticator gebruikt o.a. de datum en tijd om codes te genereren, dus moet dat hetzelfde zijn op zowel hun server als jou telefoon.

Tweede link van je is dus wel typisch want die gaat in tegen wat de authenticator bij mij aangaf als mijn tijd niet precies die van hun was. Kreeg dan steeds de melding dat ik auto aan moest zetten om met hun server te syncen.

[Reactie gewijzigd door DdeM op 23 juli 2024 16:23]

[SED]

drie keuzes dus ( deles keuze, deels config)
1: auto , sync via GSM netwerk
2: manueel: zelf kiezen en jij bent de bepalende factor voor die keuze
3: geen GSM en wel netwerk (wifi) dan via MS setting.(bij auto neem ik aan)

[tom.cx]

Klopt. Bij Apple apparaten komt hij vanuit de Apple servers.

[Migrator]

Hier op Windows 10 ook niet. Lijkt dus alleen Androids te betreffen. Ik gok dat onze telefoons de tijd synchroniseren met respectievelijk de servers van Apple en Microsoft.

[MicGlou]

Hier ook Windows 10 Mobile en bij mij wel... heb nu tijd en datum maar handmatig ingesteld ipv automatisch. Alles staat nu goed behalve de kalender... en die komt van Microsoft zelf

[Reactie gewijzigd door MicGlou op 23 juli 2024 16:23]

[Migrator]

Ik lees in de reactie van Kees dat Windows maar eens per week de tijd synchroniseert. Lijkt dus uitstel van executie te zijn i.p.v. geen last van het euvel.

[Samdolyn]

Wat is er toch mis met het gebruik van standaard libraries? Helemaal voor tijd zou dit een must moeten zijn. Niet dat duidelijk is of ze hier wel van gebruik maken, het kan ook een slechte implementatie zijn natuurlijk

[BeerenburgCola]

Als de code afgelopen 4 jaar nooit getest is met een schrikkeljaar en er wordt uitgegaan van 365 dagen in een jaar, dat gaat het vandaag pas fout. (Vandaag is de 366e dag van het jaar).

Zo vaak dat je dingen ziet als volgt:

if (num_days > 365) then doYearRollover();

*boom*

[mark-k]

Als er geen schrikkeljaar in de code zit dan had het na februari al fout moeten gaan.

[BeerenburgCola]

Sommige code telt het aantal dagen in een jaar.
Dit lijkt mij typisch zo'n geval. Zelf heb ik er ook last van gehad.

(In mijn code voorbeeld zie je dat ik dagen gebruik en niet maanden ...)

[Reactie gewijzigd door BeerenburgCola op 23 juli 2024 16:23]

[mark-k]

Ja dat snap ik, maar zonder schrikkeljaar had het na 28 februari al 1 maart moeten worden en dan dus al fout moeten zijn. Jij verwacht dus dat er wel is gedacht aan het programmeren van een schrikkeljaar, alleen dat het reset if-statement niet daarop is aangepast?

[The Third Man]

Ik vind het ook een raar verhaal. Een rollover kan je gewoon op 31 december 23:59:59 vast doen, niet na een X aantal dagen... Schrikkelsecondes worden altijd in het nieuwe jaar gedaan (vannacht ook weer), dus je hoeft ook geen seconde te wachten met de rollover.

[wurtel]

Niet waar per se.

Voor ons worden de schikkelsecondes altijd in het nieuwe jaar, maar alleen omdat 23:59:60 UTC nu eenmaal 00:59:60 MET is. Schikkelseconde wordt altijd vlak voor 00:00:00 UTC ingevoegd.

In de UK en USA heeft 2016 dus een seconde langer geduurd dan in Nederland.

Leuk detail: Bij Jools Hollands' Hootenany werd afgeteld: 10,9,8,7,6,5,4,3,2,1,1, happy new year!

[Ossi]

Precies wat ik gehad heb met een TomTom. Kon geen satelliet meer vasthouden na februari.
Bleek uiteindelijk een schrikkeljaar bug te zijn. Te sneu voor woorden eigenlijk.

[Kalief]

Precies, dan hadden systemen met een schrikkelbug de 29e februari ook niet herkend.

[itcouldbeanyone]

maar een jaar duurt altijd 365,2425 dagen
dus het gebruikmaken van een if>365 statement is dan een slordige manier van ontwetendheid van de programeur

[CAPSLOCK2000]

Als de code afgelopen 4 jaar nooit getest is met een schrikkeljaar en er wordt uitgegaan van 365 dagen in een jaar, dat gaat het vandaag pas fout. (Vandaag is de 366e dag van het jaar).

Zo vaak dat je dingen ziet als volgt:

if (num_days > 365) then doYearRollover();

De meeste programmeurs hebben geleerd dat je maar beter niet zelf met datums en tijden kan rekenen .Er zijn te veel randgevallen en uitzonderingen. Laat het over aan een library. Helaas is het zo'n ding dat eerst een keertje fout moet gaan voor je de les leert.

[Anoniem: 84766]

Ik ben blij dat ik dat soort code niet zo vaak zie. Ieder fatsoenlijk framework heeft datetime libraries en daarmee is het al lastig genoeg met tijdszones, local time etc, zeker als de basis niet in UTC is.

[Sorcerer8472]

Tele2 heeft waarschijnlijk geen in elkaar gehackt systeem maar koopt die zaken in. En dan gaat er waarschijnlijk iets anders mis

[Anoniem: 855731]

Voor hun mobiele netwerk hebben ze Nokia, en vast volgens mijn Alcatel-Lucent (tegenwoordig ook Nokia).

[SED]

Nee, ze gebruiken Huawei ( momenteel de grootste speler in GSM netwerk land)
http://www.tele2.com/medi...wei-to-deploy-4g-network/

[Jaco69]

Dat klopt niet. ReneWouters heeft gelijk over Tele2's (NL) radio netwerk.

[SED]

Bron was aardig geweest maar wat zoeken brengt me op dit:
http://www.nokia.com/en_i...ment-to-tele2-netherlands

[wildhagen]

Dan is dat vermoedelijk niet bij alle klanten het geval? Want ik zit met mijn Lumia 950XL ook bij Tele2, maar bij mij geeft hij gewoon 31-12 aan als datum?

[Anoniem: 372172]

Zie post van Evest
Sinds 30-12-16 datum naar 01-01-17

[Jeroenneman]

Tja, ik heb hier een Moto G, en die loopt ook gewoon goed met Tele2.

Niet iedereen heeft er dus last van.

[Migrator]

Met of zonder automatische tijd?

Zou natuurlijk kunnen dat sommige fabrikanten ervoor hebben gekozen een andere/meerdere servers dan die van de provider gebruiken om de tijd te synchroniseren. Eigenlijk ook gek dat zo veel telefoons afhankelijk zijn van maar één partij voor zoiets belangrijks als de tijd.

[pinpunt]

WPhone 640 automatische tijd , datum en tijd hier goed (Tele2)

[MrFax]

Kan zijn dat Windows Phone automatische correctie heeft. Zeg maar zo: Tijd kan niet kloppen(maakt opeens een grote sprong)? Use time.windows.com.

[Reactie gewijzigd door MrFax op 23 juli 2024 16:23]

[ChillinR]

Ik heb een OnePlus One met een Tele2 sim-only abonnement. De telefoon is geflashed met CyanogenMod. 'Automatic date & time (use network-provided time)' staat aan, en bij mij staat keurig 31 December, 13:42 uur.

[SED]

De vraag is dan hoe jij de datum/tijd ingesteld hebt.
settings> time and language> date and time> auto of manueel?

[Blokker_1999]

Maar waar haalt het toestel zijn tijd vandaan? Op vele toestellen kan je instellen of het toestel dit van het netwerk mag halen of niet.

[Rhndy]

Het mooie hier was dat onze wekkers niet afgingen vanochtend. Zowel op een Lumia 950XL als een Edge 7 niet. Dat is geen leuk begin van oudjaarsdag. Boeee Tele2

[Anoniem: 855731]

Mooi toch. Het is zaterdag, lekker uitslapen. En je zult toch geen uren langer slapen als de wekker niet af gaat?

[engessa]

Kon ik maar uitslapen Vandaag is gewoon een werkdag voor mij en velen met mij..

[Migrator]

Staat de tijd van je Lumia verkeerd? Ik lees van iedereen hier (mezelf incluis) dat W10M en iOS geen last hebben van dit euvel.

[Rhndy]

1 januari 2017 op automatisch instellen.
Als ik hem handmatig oo 31/12 zet dan blijft de outlook agenda toch op 1/1 staan, ook na een reboot. Super vaag dit.

[stresstak]

Het mooie hier was dat ....
Dat is geen leuk begin van ....

Wat is het nou ? Mooi of niet leuk. ?

[slaay]

Mijn modem van Tele2 VDSL geeft ook mooi 1 januari 2017 weer.

[robert_paats]

Dan is zonder meer te verklaren dat Tele2 een NTP server probleem heeft !

Ik hoop voor ze dat ze niet een willekeurige Internet NTP bron gebruiken die niet volledig betrouwbaar is maar een goede eigen NTP time server hebben ingericht.

Als je bij Tele2 klant ben dan zou ik de komende tijd ook je telefoon rekening controleren want die is tijd gebaseerd op je hoeveelheid gebelde minuten, en als ze hun referentie tijd niet op orde hebben dan kan dat ook impact hebben op je rekening.

[Jaco69]

Als je bij Tele2 klant ben dan zou ik de komende tijd ook je telefoon rekening controleren want die is tijd gebaseerd op je hoeveelheid gebelde minuten, en als ze hun referentie tijd niet op orde hebben dan kan dat ook impact hebben op je rekening.

Gelukkig wordt de hoeveelheid gebelde minuten normaal gezien niet berekend door de eindtijd van de begintijd af te trekken maar worden de seconden geteld. Dus behalve dat de tijden verkeerd kunnen zijn zou de rekening goed moeten zijn.
Maar normaal gezien geeft het netwerk ook niet de verkeerde dag door dus controleren kan geen kwaad.

[Wasrek]

Hoe worden secondes dan precies geteld bij de telefoongesprekken? Ik kan me niet voorstellen dat het iets anders is dan het verschil tussen eind- en begintijd. Waarschijnlijk wel met nog een paar sanity checks erbij.

[dgompie]

Hopelijk met behulp van systeem tijd die in (milli) seconden sinds een bepaalde start datum en tijd s.

[SED]

Ze hebben minstens een eigen server draaien
ntp.tele2.net

[CAPSLOCK2000]

Dan is zonder meer te verklaren dat Tele2 een NTP server probleem heeft !

Ik hoop voor ze dat ze niet een willekeurige Internet NTP bron gebruiken die niet volledig betrouwbaar is maar een goede eigen NTP time server hebben ingericht.

Dat is best wel knullig voor een GSM-provider want ze maken voortdurend gebruik van sattelieten met nauwkeurige klokken aan boord. Ze hoeven geen NTP-server van internet te halen, ze kunnen er zelf in voorzien.

[Rolfie]

Best lullig dat op de storing pagina bij Tele2 alleen maar een melding gemaakt wordt van "Bereikbaarheid klantenservice" issues.

Waarschijnlijk hebben ze een tijd issue om juiste informatie te geven. Je zou ook zeggen dat met dit soort foutjes mensen al vroeg wakker gebeld zouden moeten worden, wegens een groot probleem op de infra structuur. Dit zou toch om 00:01 al gedetecteerd moeten zijn door de 24 uur diensten die actief zijn voor dit soort infra structuren?

[JackBol]

Ten eerste monitort niet iedere service provider de accuraatheid zijn tijd-servers. En als die monitoring apparatuur aan dezelfde NTP server hangen hebben die natuurlijk niet door dat de tijd verkeerd staat

[Rolfie]

Blijkbaar wordt deze enkele NTP service door meerdere systemen gebruikt, aangezien er diverse issues momenteel zijn. En blijkbaar hebben ze vandaag een SPOF ontdekt (Wat waarschijnlijk bij meerdere bedrijven het geval is).
Hoe kan het zijn dat een NTP server zomaar een dag overslaat en dat andere systemen dit zo maar overnemen? Dat mag nooit gebeuren, tijd synchronisatie is best belangrijk, en als de omgeving een dag kan overslaan, dan kan het ook zo maar een maand zijn, maar in theorie ook zo maar terug in tijd. Meestal kunnen applicaties hier heel erg slecht tegen omdat transacties tijd gebaseerd zijn.
Ik heb ooit een PDC gehad in in een AD forest, dat door een hardware issue een afwijkende tijd mee kreeg, was best lullig kan je je zeggen.
Veel systemen mogen maar een afwijken van x minuten overnemen, indien het tijdverschil groter is, dan moet er een melding gemaakt worden maar mag niet overgenomen worden.

Ik zou zeer geïnteresseerd zijn de de RCA van dit probleem, is het een technisch falen geweest, of human error.

[Anoniem: 858451]

Het gaat niet over een tijdverschil, het gaat over datum.

"Hoe kan het zijn dat ... zomaar "
Dat kan je je afvragen bij elke storing. Maar het draagt niet bij aan de oplossing. De beste stuurlui staan aan wal.

[Rolfie]

Het gaat niet over een tijdverschil, het gaat over datum.

Zodra je een datums verschil hebt, dan heb je een tijdsverschil, waar veel systemen niet erg goed tegen kunnen. Dat het exact een dag verschil is, maakt daarbij niet zoveel uit.

Dat kan je je afvragen bij elke storing.

Dat moet je je ook afvragen bij elke grote storing. Zeker bij een storing die men nu heeft.

Maar het draagt niet bij aan de oplossing. De beste stuurlui staan aan wal.

Waar mensen werken, worden fouten gemaakt. Been there, done that. Meestal zou bij mij namelijk nu mijn telefoon overgaan, of ik nu standby heb of niet.
Ik sta dus meestal niet aan wal, maar zit in de reddingsboot die naar het schip vaart.
Ik vind het persoonlijk ook een heel interessant probleem een dag tijds verschil.
Hoe lossen we het op? En daarna hoe kunnen we dit voorkomen, hoe hadden we dit kunnen voorkomen. Dat beschrijf juist een RCA.

[Anoniem: 858451]

Tja, systemen kunnen ook niet goed tegen gemorste koffie of stroomonderbreking. Vertel eens wat nieuws. Je zou het moeten omdraaien, waarom draaien er systemen die niet tegen tijdsverschil kunnen (single point of failure)? Misschien heeft Tele2 deze hobbel al lang genomen en lossen ze dit achteraf met een routine-handeling op. Misschien heeft dit probleem zich bij tele2 niet intern voorgedaan, alleen bij klanten. Als buitenstaander weet je het niet.

[JackBol]

Ironisch genoeg is het een feit dat wanneer je netwerk goed ontworpen is, human error percentueel gezien een groter gedeelte van de fouten veroorzaakt

Aangezien we vannacht een schrikkelseconde krijgen, verwacht ik dat een admin aan NTP servers heeft gezeten. Verder heb ik nergens anders signalen gevonden van NTP implementaties met het zelfde probleem, en ik neem aan dat Tele2 niet hun eigen NTP implementatie heeft geschreven.

[sekeroglan]

Niet opgevallen en zie het ook nu pas!

Ik kwam er achter omdat ik Authenticators(google) foutmeldingen krijg met 2 stap verificaties Maar zelf niet naar de datum gekeken.
Door in de app Tijdcorrectie te toepassen bij instellingen doen de codes het in elk geval wel.

[Jirnsum]

Ik heb authenticator inderdaad zowel op iphone als android draaien en ze hebben momenteel inderdaad totaal andere waardes.

Overigens werkte de ING app wel gewoon: scande daar ook een code van het scherm. Blijkbaar neemt die de datuim van het toestel niet mee

[Reactie gewijzigd door Jirnsum op 23 juli 2024 16:23]