Apples iOS kampt opnieuw met wintertijdproblemen

Gebruikers hebben problemen gemeld bij de overgang van de zomertijd naar wintertijd in iOS 7. Alhoewel de systeemtijd op iOS-apparaten correct werd aangepast, lijkt de agendafunctionaliteit dit niet te hebben overgenomen, net als enkele andere apps.

De problemen die ontstonden bij de overgang op de wintertijd werden door iOS 7-gebruikers onder andere op GoT gemeld. Zo staat de tijdsaanduiding in de agenda-applicatie nog op de zomertijd. Ook stellen gebruikers dat het probleem met de tijdsaanduiding voor komt in andere applicaties, waaronder de ingebouwde weer-app. Waarschijnlijk is het noodzakelijk dat Apple met een fix komt om de apps de juiste tijd aan te laten geven.

Het is niet de eerste keer dat Apples mobiele besturingssysteem met problemen met de tijdsweergave kampt na de overgang op winter- of zomertijd. Eerder faalde de wekker in iOS toen de wintertijd inging. Overigens gebeurde dat ook bij de jaarwisseling. Bij de meest recente jaarwisseling kampte iOS met problemen in de 'niet storen'-functie.

Reacties (198)

[Argantonis]

Jammer, dit soort functionaliteit moet je natuurlijk heel goed testen, juist omdat het enorm makkelijk is om er fouten in te maken. Datums, tijd en tijdzones zijn enorm lastig om over te redeneren als ontwikkelaar, maar dat is een bekend gegeven dus daar moet je dan wat mee doen.

Ik heb zelf veel van dit soort functionaliteit gebouwd en deze uitleg vond ik erg behulpzaam: http://www.odi.ch/prog/design/datetime.php

[Reactie gewijzigd door Argantonis op 24 juli 2024 22:39]

[Rafe]

IK weet niet wat Apple gebruikt voor iOS, maar voor OS X gebruiken ze de Olsen database en daarmee gaat het voor heel veel systemen goed... beetje vreemd dat het nog steeds verkeerd gaat

[Durandal]

Bij de oudere iOSen gaat het ook goed, dus dan vraag ik me af waarom er niet is doorgegaan op de oude code die bewezen goed is.

[johnkeates]

Om dat je zo nu en dan beter opnieuw je software kan engineeren in plaatst van 7 releases lang met oude code werken.

Waarschijnlijk is op het moment ook niet een stuk bestaande code 'weggegooid' en opnieuw geschreven, maar een gehele app vervangen door een andere app.

[Argantonis]

Om dat je zo nu en dan beter opnieuw je software kan engineeren in plaatst van 7 releases lang met oude code werken.

Waarschijnlijk is op het moment ook niet een stuk bestaande code 'weggegooid' en opnieuw geschreven, maar een gehele app vervangen door een andere app.

Het is juist een van de klassieke fouten in software-engineering om helemaal vanaf scratch opnieuw te beginnen. Joel Spolsky heeft daar een mooi artikel over op http://www.joelonsoftware.com/articles/fog0000000069.html

[johnkeates]

Ja, maar het is ook een klassieke fout om generatie op generatie je codebase niet te willen vernieuwen. Kijk bijvoorbeeld naar windows.

[nIghtorius]

Ja, daarom heeft Windows maar een kleine marktaandeel van +- 91%.. Echt een klassieke fout.. Kan echt niet.

[johnkeates]

Je weet dat marktaandeel en kwaliteit van software niet echt een direct verband hebben he? Het gaat hier om de technische kant, niet om de business kant, fanboy kant, huis-tuin-keuken kant of de marktaandeel kant. Je kan hoog of laag springen, maar hoge kwaliteit software engineering zie je niet op het moment dat er 20 jaar oude code gerecycled wordt om dat het de business goed uit komt en backwards compatibility met rotzooi uit 1995 nodig is.

[Durandal]

Om dat je zo nu en dan beter opnieuw je software kan engineeren in plaatst van 7 releases lang met oude code werken.

Blijkbaar niet dus. Je moet tenminste kijken naar de oude code om te zien wat daar geleerd is.

[THID]

Waarschijnlijk is op het moment ook niet een stuk bestaande code 'weggegooid' en opnieuw geschreven, maar een gehele app vervangen door een andere app.

dat is in essentie hetzelfde.

[johnkeates]

Niet precies, want het gaat om een compleet andere app. Het is niet zo dat ze de oude App genomen hebben, een 'beetje' code hebben aangepast, en verder gingen, en nu opeens bugs hebben.

[Argantonis]

IK weet niet wat Apple gebruikt voor iOS, maar voor OS X gebruiken ze de Olsen database en daarmee gaat het voor heel veel systemen goed... beetje vreemd dat het nog steeds verkeerd gaat

Ik weet ook niet welke database ze op iOS gebruiken, maar hoe dan ook, dat betekent natuurlijk niet dat alles automatisch goed gaat, het betekent alleen dat je wat goede stamdata hebt.

[WhizzKid-Eddy]

Als Apple ervan uitgaat dat deze stamdata altijd klopt, zonder te controleren of dit ook zo is, dan zit jij als gebruiker met de gebakken peren... of appels in dit geval.

[Argantonis]

Als Apple ervan uitgaat dat deze stamdata altijd klopt, zonder te controleren of dit ook zo is, dan zit jij als gebruiker met de gebakken peren... of appels in dit geval.

Maar het gaat helemaal niet om de stamdata (en de Olsen database klopt wel hoor, daar hoef jij je geen zorgen om te maken) maar om de implementatie van de calendar-app zelf.

[FreshMaker]

[...]


Maar het gaat helemaal niet om de stamdata (en de Olsen database klopt wel hoor, daar hoef jij je geen zorgen om te maken) maar om de implementatie van de calendar-app zelf.

Ik vermoed dat dat eerder op het systeem-niveau niet goed gaat.
Aangezien een calender-app eigenlijk geen systeempermissie hoeft te hebben, is het logisch dat het gelijkzetten van de klok niet (zomaar) via een omweg gaat.

Misschien een geval 'overprotectie' waar Apple over het algemeen goed in scoort, en juist nu 'even' niet.

[Josh60]

En wat ben je dan .....?

[FreshMaker]

En wat ben je dan .....?

?

Die vat ik niet helemaal

[LollieStick]

Deze bedoelt Josh60

http://www.watbenjedan.nl/

[Reactie gewijzigd door LollieStick op 24 juli 2024 22:39]

[johnkeates]

Volgens mij gebruiken ze dezelfde subsystemen, ik vind het ook raar dat het daar niet goed gaat, maar op OS X wel. Op OS X is er in de laatste 5 of 6 major releases zelfs geen enkel probleem met tijd/datum geweest dacht ik!

Misschien dat het op iOS wat lastiger is met de beperkte resources en extremere sandboxing?

[Argantonis]

Volgens mij gebruiken ze dezelfde subsystemen, ik vind het ook raar dat het daar niet goed gaat, maar op OS X wel. Op OS X is er in de laatste 5 of 6 major releases zelfs geen enkel probleem met tijd/datum geweest dacht ik!

Misschien dat het op iOS wat lastiger is met de beperkte resources en extremere sandboxing?

Ik denk dat het gewoon aan het team ligt dat die agenda implementeert. Een device dat iOS7 draait is vaak sneller dan de meeste desktops van een aantal jaar geleden, laat staan die van ruim 40 jaar geleden toen ze dit soort dingen ook al bedachten en konden implementeren. In welke mate ze iets sandboxen lijkt me niet zo relevant, maar misschien kan je dat uitleggen? Ik ben geen Objective-C developer maar ik neem aan dat de taal wel met een zootje aan libraries komt waarmee je dit soort berekeningen kan uitvoeren. Gelet op het feit dat de tijd van het device zelf wel netjes werd ingesteld denk ik dat er niet iets fundamenteels fout zit in die implementatie.

[Speleding]

Ik heb zelf nogal wat tijdfuncties geprogrammeerd en het omrekenen van een tijdstip van GMT naar lokale tijd of vice versa kost veel meer moeite dan je zou denken. Het is echt bizar hoeveel rare uitzonderingen er in de enorme Olson database staan, en hoeveel rare uitzonderingen je kan krijgen als je net in de overgangsperiode van zomer naar winter zit of vice versa. Je komt er dan al snel op uit dat je een serie offsets 1 keer uitrekent en die in een cache stopt. En het is altijd makkelijk om een cache te vergeten.

Maar toch, je zou zeggen dat zoiets nu zo langzamerhand niet meer zou mogen gebeuren, zeker niet bij Apple. Je verwacht toch dat ze een integratietest hebben geschreven die al die rare uitzonderingen even langsloopt.

[Argantonis]

Ik heb zelf nogal wat tijdfuncties geprogrammeerd en het omrekenen van een tijdstip van GMT naar lokale tijd of vice versa kost veel meer moeite dan je zou denken. Het is echt bizar hoeveel rare uitzonderingen er in de enorme Olson database staan, en hoeveel rare uitzonderingen je kan krijgen als je net in de overgangsperiode van zomer naar winter zit of vice versa. Je komt er dan al snel op uit dat je een serie offsets 1 keer uitrekent en die in een cache stopt. En het is altijd makkelijk om een cache te vergeten.

Daarom doe je alle berekeningen ook gewoon in UTC en formatteer je de date als een string pas op het moment dat je iets aan een gebruiker toont. Natuurlijk zijn bepaalde functies zoals het verkrijgen van het begin van de huidige dag wel weer tijdzone-afhankelijk, maar over het algemeen heb je er met omrekenen niks mee te maken, sterker nog, daar zou je helemaal niet mee bezig moeten hoeven zijn als de applicatie in de basis goed is opgezet, dus tijden in UTC opslaat.

En bij zoiets belangrijks als de Calendar-app van iOS zou ik zeker wel verwachten dat dit goed getest wordt.

[Reactie gewijzigd door Argantonis op 24 juli 2024 22:39]

[.oisyn]

Daarom doe je alle berekeningen ook gewoon in UTC en formatteer je de date als een string pas op het moment dat je iets aan een gebruiker toont.

Lekker makkelijk gedacht. Als ik in mijn agenda in de zomer een dagelijks terugkerend item om 12:00 (UTC 10:00) inplan, dan wil ik dat dat item op zondag 27 oktober ook gewoon om 12:00 plaatsvindt (UTC 11:00), en niet ineens om 11:00 (de originele UTC 10:00 dus) omdat de klok een uur terug is gezet. Dus nee, met gewoon blind vertrouwen op UTC tijden ben je er absoluut niet.

[Reactie gewijzigd door .oisyn op 24 juli 2024 22:39]

[Argantonis]

[...]

Lekker makkelijk gedacht. Als ik in mijn agenda in de zomer een dagelijks terugkerend item om 12:00 (UTC 10:00) inplan, dan wil ik dat dat item op zondag 27 oktober ook gewoon om 12:00 plaatsvindt (UTC 11:00), en niet ineens om 11:00 (de originele UTC 10:00 dus) omdat de klok een uur terug is gezet. Dus nee, met gewoon blind vertrouwen op UTC tijden ben je er absoluut niet.

Dat hangt heel erg van de situatie af. In dit geval wil je dat waarschijnlijk inderdaad wel. Maar wat als je jouw afspraak zou inplannen maar dan om 2:30? Dat betekent dat je jouw afspraak een keertje 2x zou hebben en een keertje helemaal niet.
En wat als je jouw afspraak niet dagelijks maar elk uur herhaalt? Dat is voor een agenda-afspraak niet zo logisch maar voor scheduled actions op een of andere server wel. Dan zou je in jouw geval compenseren en dus wederom een keer per jaar de actie compleet overslaan en een keer per jaar 2 maal uitvoeren.

Dus ja, met dit soort gevallen moet je inderdaad rekening houden, maar dat betekent niet dat je niet met UTC moet rekenen in het algemeen.

[Reactie gewijzigd door Argantonis op 24 juli 2024 22:39]

[.oisyn]

maar dat betekent niet dat je niet met UTC moet rekenen in het algemeen.

Daar gaat het ook niet om, ik reageer op het feit dat jij de UTC als heilige graal zag, terwijl die dat soort problemen helemaal niet op gaat lossen.

Om je originele opmerking even te quoten:

maar over het algemeen heb je er met omrekenen niks mee te maken, sterker nog, daar zou je helemaal niet mee bezig moeten hoeven zijn als de applicatie in de basis goed is opgezet, dus tijden in UTC opslaat.

Het is gewoon een feit dat het werken met "menselijke" tijden echt vele malen complexer is dan iedereen op het eerste gezicht denkt. Vrijwel elke programmeur denkt er te makkelijk over, en iedereen gaat vroeg of laat een keer de mist in. Door de opmerking te maken dat je "gewoon in UTC moet rekenen" bagatelliseer je de boel echt enorm.

[Reactie gewijzigd door .oisyn op 24 juli 2024 22:39]

[Argantonis]

Het is gewoon een feit dat het werken met "menselijke" tijden echt vele malen complexer is dan iedereen op het eerste gezicht denkt. Vrijwel elke programmeur denkt er te makkelijk over, en iedereen gaat vroeg of laat een keer de mist in. Door de opmerking te maken dat je "gewoon in UTC moet rekenen" bagatelliseer je de boel echt enorm.

Mijn opmerking over in UTC rekenen was niet bedoeld als dat het de heilige graal was die alles op zou moeten lossen, maar als reactie op een andere comment waarbij gezegd wordt dat tijden omgerekend moesten worden van tijdzone naar tijdzone, maar dát is niet echt aan de orde. Een bepaalde tijd/datum is zoals je ongetwijfeld weet simpelweg een Long value en alle andere implementaties gaan nog voor veel meer kopzorgen zorgen.

Dat het veel complexer is dan de meeste mensen denken dat weet ik, geloof me

[RuddyMysterious]

Probleem is dat veel landen in Europa gebruik maken van CET, maar in de zomer van CEST. Hoe kan een programma weten of dat bij een specifiek iemand inderdaad het geval moet zijn, dat er gewisseld wordt tussen CET en CEST? Daarom dat er bij het instellen van alle regionale gegevens ook gevraagd wordt in welke tijdzone met bijhorende resem steden je je bevindt, omdat niet elke UTC+1 zone dezelfde overgang tussen zomer en winter meedoen.

[Argantonis]

Probleem is dat veel landen in Europa gebruik maken van CET, maar in de zomer van CEST. Hoe kan een programma weten of dat bij een specifiek iemand inderdaad het geval moet zijn, dat er gewisseld wordt tussen CET en CEST? Daarom dat er bij het instellen van alle regionale gegevens ook gevraagd wordt in welke tijdzone met bijhorende resem steden je je bevindt, omdat niet elke UTC+1 zone dezelfde overgang tussen zomer en winter meedoen.

Klopt ja, dat zeg ik ook een paar posts naar boven (Argantonis in 'nieuws: Apples iOS kampt opnieuw met wintertijdproblemen'), het wordt zelfs nog complexer omdat er door de historie heen ook nog wijzigingen zijn geweest (zie Argantonis in 'nieuws: Apples iOS kampt opnieuw met wintertijdproblemen')

[HokiPoki]

Ik heb zelf al helemaal geen specifieke kennis over het programmeren met tijd, maar moet je in de app niet 'gewoon' de tijdszone van de gebruiker op het moment van invoeren opslaan samen met de tijd?
Dan is elke berekening die je doet t.o.v. van de gelokaliseerde systeemtijd.
Het 'enige' wat je dan overhoud is de conversie van standaard systeemtijd naar gelokaliseerde tijd (wat Speleding aangaf niet altijd eenvoudig te zijn).

[Argantonis]

Ik heb zelf al helemaal geen specifieke kennis over het programmeren met tijd, maar moet je in de app niet 'gewoon' de tijdszone van de gebruiker op het moment van invoeren opslaan samen met de tijd?
Dan is elke berekening die je doet t.o.v. van de gelokaliseerde systeemtijd.
Het 'enige' wat je dan overhoud is de conversie van standaard systeemtijd naar gelokaliseerde tijd (wat Speleding aangaf niet altijd eenvoudig te zijn).

Daar komt het wel een beetje op neer, alleen dat zou je niet bij elke invoeractie willen doen (ook omdat de gebruiker wel eens in het buitenland kan werken o.i.d., dus je wil zoiets ook expliciet maken) maar als setting per user in de applicatie

Om het op het web nog wat complexer te maken moet je er ook nog rekening mee houden dat de browser de tijdzone niet kan doorsturen naar de webserver, alleen maar de huidige offset vanaf UTC. Dat betekent dat deze tijdzone dus niet meer klopt nadat je van zomer/wintertijd bent veranderd. Dus je zal ook daar een optie moeten inbouwen dat gebruikers hun tijdzone invoeren. En dan nog kan je afwijkingen krijgen ten opzichte van wat een gebruiker in zijn browser ziet als ze dat niet goed doen, tenminste als je datums als primitief object naar de client stuurt en de browser zelf de datum laat renderen. Hier zijn zat onderwerpen over op stackoverflow mocht je geïnteresseerd zijn. Het is hoe dan ook inderdaad niet simpel, maar als je tijden NIET in UTC opslaat in de basis dan haal je jezelf een hoop problemen op de hals bij applicaties die gebruikers in verschillende tijdzones hebben.

[RuddyMysterious]

Het gebruiken van UTC impliceert daarmee niet dat die direct de zomer- en wintertijd van UTC gaat gebruiken, dat kan nog steeds lokaal gebeuren.

[.oisyn]

UTC kent geen zomertijd. In de winter zijn we UTC+1 en in de zomer zijn we UTC+2.

[Reactie gewijzigd door .oisyn op 24 juli 2024 22:39]

[Verwijderd]

De systeemtijd op iOS7 is juist, alleen de afbeelding ervan in de iOS7 kalender applicatie (het streepje) is niet juist. Misschien wordt een verkeerde API call gebruikt in deze applicatie?

In die zin is het daylight saving probleem ook minder erg dan bij vorige versies van iOS, daar was echt de systeemtijd de kluts kwijt, nu is het enkel op applicatie niveau dat er iets mis gaat.

[johnkeates]

Bij Android was er zat mis met tijden, wintertijden en jaarwisselingen hoor Wat dacht je van de camera app die na iets van 300 dagen geen foto's meer kon maken door een bug in de datum/tijd implementatie?

[calvinturbo]

Ik werk al heel lang met Android en ik volg elke dag het nieuws, maar ik heb dat nog nooit meegekregen.. Zal wel een toestel specifieke bug zijn geweest

[WhizzKid-Eddy]

http://www.zdnet.com/blog...oid-phones-is-wrong/19387

Een linkje naar een oud bericht waarin gesproken wordt over het niet juist synchroniseren van android met GPS data, waardoor de tijd niet juist wordt weergegeven. Blijkbaar ging dat onder iOS wel goed, omdat iOS dit blijkbaar compenseert door extra seconden aan de tijd toe te voegen. Niet de meest elegante oplossing naar mijn idee, maar het werkt wel.

[Kevinp]

Ik snap dit ook niet goed. Dit is namelijk behoorlijk makkelijk te testen. Maar ja het zal volgende keer wel opgelost zijn.

[robenroute]

Even je tijdzone-instelling van automatisch af zetten, je kalender openen (rode tijdslijn moet weer in sync staan als het goed is) en vervolgens je tijdzone-instelling weer terug op auto (als je dat wil).

[Me_Giant]

Werkt hier niet op een iPhone 4.

[accountabc]

Zeker voor Apple devices waar het gebruiksgemak altijd zo van wordt geprezen vind ik het erg slordig dat er toch elke keer weer bugs opduiken die met iets simpels als de tijdweergave te maken hebben. Waarom lijken alle grote OS bouwers wel een werkende klok implementatie te kunnen bouwen maar Apple niet? Zeker gezien de kritiek die ze destijds kregen toen de wekkers niet afgingen zou je toch verwachten dat ze tijd gerelateerde zaken tegenwoordig fatsoenlijk testen.

[CyBeR]

Zeker voor Apple devices waar het gebruiksgemak altijd zo van wordt geprezen vind ik het erg slordig dat er toch elke keer weer bugs opduiken die met iets simpels als de tijdweergave te maken hebben.

Als je niet weet waar je het over hebt, en dat bewijs je door te zeggen dat tijdweergave iets "simpels" is, kun je beter je mond houden. Tijdweergave in een ideale wereld waarin alleen TAI bestaat is inderdaad simpel. In de echte wereld echter is 't behoorlijk complex en zijn er veel niet-voordehandliggende zaken die fout kunnen gaan.

Zeker gezien de kritiek die ze destijds kregen toen de wekkers niet afgingen zou je toch verwachten dat ze tijd gerelateerde zaken tegenwoordig fatsoenlijk testen.

Dat dan weer wel.

[Jasper Janssen]

Uhm. Alle andere grote softwarebouwers kunnen het *ook* niet. Hoor je een stuk minder over, maar die bugs zijn er wel degelijk.

[curumir]

Dit moet toch een van de droevigste topics zijn sinds lange tijd.

De tijd wordt goed berekend en staat goed op de iPhone, de wekker werkt en vrijwel alles lijkt gewoon goed te gaan (smsjes, whatsapp etc geeft de juiste tijd aan).

Wat gaat er dan wel fout; ik heb twee dingen kunnen ontdekken:
Zoals je op het plaatje wat bij het artikel kun zien wordt het lijntje met de tijd op de verkeerde plek gezet. Ja, werkelijk, dat is de grote fout in de agenda app. De tijd op de lijn is correct, de tijd op de iPhone is correct en (heb ik net getest) ondanks dat het lijntje verkeerd staat worden notificaties op de juiste tijd gemeld. (Voor de duidelijkheid, ik zag het eerst niet eens: 10:03 is de correcte tijd, maar de lijn staat op 11:03 wat fout is).
Het is dus puur een cosmetische interface kwestie. Slordig, maar dat is ook alles.

De fout in de weer app is iets ernstiger, maar ook grotendeels cosmetisch. Het is nu 16:10, maar de weer app laat het weer zien vanaf 17:00. Wederom is de inhoud wel goed, de zonsondergang staat namelijk wel op de wintertijd, namelijk 17:20ish, afhankelijk van waar in Nederland je woont.

Verder heb ik nog niks kunnen ontdekken wat fout gaat.

Samenvattend, er gaat niks mis met het berekenen van de tijd en wintertijd in iOS 7, maar op twee plekken wordt het niet 100% in de interface weergegeven. Is dit werkelijk een topic met meer dan 100 reacties waard op een tech-site?

[Reactie gewijzigd door curumir op 24 juli 2024 22:39]

[madass]

Dat komt omdat de berichtgeving gewoon vaag is. Er wordt niet uitgelegd wat er precies aan de hand is, waardoor mensen geen goed beeld kunnen krijgen en maar wat dingen gaan roepen.

[loeberce]

Maar het frappante is dat de fout in de weer-app al voor het ingaan van de wintertijd in NL een probleem was. Ik zit in Kazachstan en daar werd de tijd in de weer-app verkeerd weergegeven tot afgelopen weekend. Nu staat hij weer goed.

[horizon1978]

Dat klopt allemaal wel en bij andere systemen zal er minder over gepraat worden maar het komt door Apple zelf. Het komt doordat ze zichzelf profileren als het best mobiele OS systeem dat er is, dan is de reactie als iets fout is altijd groter.

[Verwijderd]

Ach je wilt niet weten hoeveel dingen er fout gaan op apparaten van duizenden euro's. Daarbij vergeleken is dit een klein foutje.

[ikbenerniet]

Gewoon een simpel idee: laten we nu eens alle tijdzones en tijdverschuivingen afschaffen, en overal het 24-uurs kloksysteem gebruiken. De GMT kan gewoon overal gebruikt worden.
voordeel: met deze standaard wordt alles vele malen simpeler. Zeker internationaal gezien. 1030 is overal 1030. overal tegelijk nieuwjaar etc. etc.
nadeel(?): de tijden zijn anders, zo kan het van 2000 tot 0800 overdag zijn.

Hier lijkt me het voordeel wel vele malen beter dan dat het nadeel voor last met zich mee brengt.

Kan iemand een reden verzinnen waren we deze versimpeling niet meteen gaan doorvoeren? Dit lijkt me namelijk best wel logisch om in te voeren, net als internationale standaarden voor afstand etc.

[Fjerpje]

Heeft voornamelijk met het feit te maken dat de zon om 12 uur 's middags overal ter wereld op hetzelfde punt staat. Het afschaffen van tijdzones zal zeker geen grote veranderingen met zich mee brengen.

In de ruimtevaart werken ze overigens wel met een universele tijd. Het punt is echter dat je veel gewoonten op de schop moet gooien. Theoretisch gezien is één universele tijdzone wel mogelijk, maar loopt je dus tegen de acceptatie van mensen in andere landen aan die dan moeten switchen van bijvoorbeeld 12 uur 's middags naar 12 uur 's nachts; het zit dus ook voornamelijk tussen de oren.

De ingebruikname van tijdzones was overigens al een hele stap omdat vroeger iedereen overal ter wereld in verschillende steden hun eigen tijd hadden. Een volgende stap zou een universele tijd kunnen zijn mits iedereen dat natuurlijk wil. Systeemtechnische gezien levert het voordelen op maar verder verandert er niks.

[Reactie gewijzigd door Fjerpje op 24 juli 2024 22:39]

[Verwijderd]

In de luchtvaart is de tijd ook altijd UTC en is lokale tijd niet veel gebruikt. Het is dus zeker wel toepasbaar maar het zal nooit gebeuren omdat hoe verder de tijdzone van UTC afwijkt de tegenstand groter zal worden. Denk je nu echt dat ze in de USA op London tijd gaat? Ze zijn daar nog niet eens klaar voor meters en kilo's.

[.oisyn]

Theoretisch gezien is één universele tijdzone wel mogelijk

Een mondiale nog wel, een universele (in de letterlijke betekenis van het woord) wordt het wat lastig. Tijd is relatief en de verloop van tijd hangt van je referentiekader af. Zo tikt een klok op Jupiter langzamer dan eentje op aarde, die op zijn beurt weer langzamer tikt dan eentje in de ruimte (gravitationele tijdsdilatie)

[Deveon]

Wel beetje onhandig als het in de middag opeens de volgende dag is.. En wat noemen we dan ochtend, middag, avond en nacht? Wordt heel verwarrend wanneer je een vliegreis maakt, want welke tijd is normale tijd?

Ontopic : storm in een glas water..

[Technomania]

Je vergeet één ding, Als het hier licht is, is het in de US donker.. Moeten al die amerikanen dan in het donker werken, en overdag in hun bed liggen?

[mystic101]

Nee, je gaat nog steeds gewoon werken wanneer het licht wordt. Het is dan alleen niet 8 uur maar bijvoorbeeld 14 uur.

[aval0ne]

En dat omdat Apple niet kan programmeren? Beetje drastisch niet?

[Argantonis]

Gewoon een simpel idee: laten we nu eens alle tijdzones en tijdverschuivingen afschaffen, en overal het 24-uurs kloksysteem gebruiken. De GMT kan gewoon overal gebruikt worden.
voordeel: met deze standaard wordt alles vele malen simpeler. Zeker internationaal gezien. 1030 is overal 1030. overal tegelijk nieuwjaar etc. etc.
nadeel(?): de tijden zijn anders, zo kan het van 2000 tot 0800 overdag zijn.

Hier lijkt me het voordeel wel vele malen beter dan dat het nadeel voor last met zich mee brengt.

Kan iemand een reden verzinnen waren we deze versimpeling niet meteen gaan doorvoeren? Dit lijkt me namelijk best wel logisch om in te voeren, net als internationale standaarden voor afstand etc.

Dat idee is niet origineel en ik ben er ook zeker een voorstander van. Helaas maakt het voor veel applicatieontwikkeling nog niet eens zoveel uit, omdat je ook met datums in het verleden moet kunnen omgaan. Dit is dan ook de reden dat een tijdzone-database niet een simpele regio + tijdzone-offset is met nog de datums waarop ze eventueel daylight savings time voeren, maar een complexe database met alle veranderingen en tijdzones door de jaren heen. Ik quote even de wikipedia-pagina (https://nl.wikipedia.org/wiki/Tijdzone) over de Nederlandse situatie:

In Nederland was de situatie ingewikkelder: in 1866 besloten de Nederlandse spoorwegbedrijven dat alle stationsklokken de tijd van Amsterdam zouden aanhouden. Sommige gemeenten besloten dat hun burgerlijke tijd gelijk zou zijn aan de spoortijd, maar andere hielden vast aan de lokale tijd, waardoor de torenklok niet gelijk stond met de stationsklok.

In 1892 besloten de spoorwegen in Nederland de tijd van Greenwich aan te houden. Deze was 19 minuten en 32,13 seconden achter op de tijd van Amsterdam. De meeste plaatsen in Nederland hielden zich inmiddels aan de Amsterdamse tijd. Pas in 1909 hanteerden alle Nederlandse plaatsen dezelfde tijd, want toen werd bij wet bepaald dat de Amsterdamse tijd voor heel Nederland, en dus ook voor de spoorwegen, zou gelden. Met ingang van 17 maart 1937 werd de tijd vereenvoudigd tot UTC + 20 minuten.

In 1940 werd door de Duitse bezetter zowel in Nederland als België de Midden-Europese Tijd ingevoerd, die een uur voor is op de tijd van Greenwich en ruim 40 minuten op de tijd van Amsterdam. (In België gold dit ook tussen 1914 en 1918 in de door de Duitsers bezette gebieden.)

Van 1916 tot 1945 kende Nederland zomertijd om het energieverbruik te verminderen; in België was dat van 1918 tot 1945. In 1977 werd de zomertijd in beide landen opnieuw ingevoerd.

Dus wat we ook doen, helaas zijn ontwikkelaars voorlopig nog niet af van dit soort problematiek.

[Fab1Man]

Hoe komt het toch dat de wintertijd/zomertijd als probleem keer op keer blijft terugkomen? Wat is er OS-technisch zo challenging aan dat dat niet begrepen wordt?

[Verwijderd]

Ik lees dat het veel op agendas voorkomt, is het niet zo dat die de tijd vertalen vanaf de server? Die server staat in een andere tijdzone waarschijnlijk...

[johnkeates]

Nou, niet perse. De uitwisselingsformaten houden daar al rekening mee en drukken de tijd vaak in UTC + tijdzone uit, of GMT.

[teacup]

Die richting ging ik ook op, zolang je op je device een bepaalde tijdzone instelt moet dit goed gaan. Dit klinkt mij als slordig programmeren in de oren. De applicatieprogrammeurs lijken mis geschoten te hebben met het oppakken van deze systeemtijd. Voor mij geen nieuws. In software kunnen om de twee jaar regressieproblemen optreden van functies die goed hebben gewerkt. Verwijtbare oorzaken: fragmentatie van werkzaamheden, slecht change management en een te laag budget voor functionele eindcontroles van de output.

Tik op de vingers van Apple? Nou nee, dit is een probleem in de gehele software industrie, dus Apple fans hou de tenen even in en laten we kijken wat we eruit kunnen leren. Dat is constructiever, en dat is waar Tweakers voor is bedoeld, een gezonde neutrale kritische blik. Laten we onafhankelijkheid alsjeblieft koesteren, hoe enthousiast we ook over een merk kunnen zijn.

[Avalaxy]

Kijk dit maar als je niet snapt wat er zo challenging aan is: http://www.youtube.com/watch?v=84aWtseb2-4

[lenwar]

Dit filmpje geeft alleen maar de (on)zin van de tijdverschuiving aan. Niet waarom OS (en andere software) makers er zo veel moeite mee hebben om het goed te implementeren.


Je kan met zdump op een Linux systeem zien dat ze daadwerkelijk een tabel bijhouden per tijdzone.

Dit is echter alleen de weergave tijd die wordt aangepast (mits je hardware op UTC tijd loopt). Daarnaast zie je dat binnen UNIXen software er anders mee omgaat... Zo doet de Linux-crond het altijd eenmaal (dus ook al wordt het op een bepaald moment twee keer 02:30, dan laat hij de job maar één keer lopen. Op Solaris zie je dat het wel twee keer zal doen als de klok achteruit gaat.
Als de klok vooruit gaat slaat Solaris hem over, en gaat Linux hem inhalen (dacht ik)

Dit gedrag kan problematisch zijn voor tijdgebonden automatisering... (denk aan internationale financiele transacties waar per uur rentes worden berekend, enz enz enz...)

[Verwijderd]

Ik vind persoonlijk dat dit filmpje precies weergeeft waarom het zo complex is. Vanaf 4:30 geeft deze precies weer dat agenda afspraken en verzoeken over tijdzones heen gaan. Deze (steeds veranderende) verschillen zorgen ervoor dat agenda afspraken complex worden.

Apple is niet de enige met timezone problemen. Exchange en Outlook hebben in het verleden ook veel problemen meegemaakt en zijn in sommige internationale bedrijven nog steeds problematisch:

http://support.microsoft.com/gp/cp_dst/nl
http://support.microsoft.com/kb/971878
http://blogs.technet.com/...ased-february-1-2007.aspx
http://blogs.technet.com/...-and-libya-time-zone.aspx

[DJMaze]

Dat niet alleen, mijn Nokia Lumia 510 test phone stond vanochtend opeens op "0:30" en bleef daar vast op staan.
Vervolgens de tijd goed zetten, 3x moest dat gebeuren omdat hij 3x een andere tijd aan gaf dan dat ik had ingevuld.

[Paul - K]

Erg interessant verhaal, je gaat je direct afvragen of we die DST nog wel willen houden of niet.

[g4wx3]

Ik heb altijd getwijfeld aan de voordelen, maar de nadelen zijn overduidelijk: Baby die wakker wordt om 5 uur en zijn fles wilt ipv 6 uur,

Koeien die gemolken willen worden om 4 uur, ipv 5 uur, De melk die een uur langer moet wachten voor ze wordt opgehaald.

Die DST gaat veel verder dan je zou denken.
En nu s'avonds is het in een klap veel donkerder, waardoor er meer ongevallen zijn..

Zouden beter eigenlijk blijven op het zomeruur (heeft meer voordelen dan blijven op het winteruur)

[PolarBear]

Nou het is complex, maar challenging... Er zijn heel veel uitzonderingen in de tijdzones (zie ook de al eerder genoemde Olsen Database) maar voor de rest is het allemaal vrij simpel, in de zin dat het allemaal eenvoudig berekenbaar is. Je moet alleen wel goed opletten wat je doet en goed testen. Maar laten we wel wezen tijdzones, zeker in een mobiel device, is natuurlijk een core onderdeel van het OS (de localization).

Wat er verder nog wel eens mis gaat is dat programmeurs van applicaties niet altijd de juiste API gebruiken en niet de gevolgen overzien van het niet of verkeerd gebruik van API's. Ik ken iOS/XCode niet zo goed maar ik ga er van uit dat er net als in .Net er een goede DateTime en Localization ondersteuning is.

[Gropah]

Intressant filmpje ware het niet dat het het fout heeft voor Europa aangezien die al een tijd lang gezamelijk overgaan.

[Reactie gewijzigd door Gropah op 24 juli 2024 22:39]

[Verwijderd]

Zo challenging is het echt niet... digitale horloges kunnen het al 10 tallen jaren prima.

Als jij een horloge en een iPhone hetzelfde laat doen heb je helemaal gelijk. En de iPhone laat de tijd dan ook keurig zien zonder fouten. Het zijn applicaties die de fout hebben. Jouw horloge heeft geen applicaties. De vergelijking is daarom niet valide.

Neem van de ontwikkelaars hier aan dat vrijwel elke berekening met tijd en datum ingewikkeld en foutgevoelig is. Gewoon de tijd 'syncen' zoals jij voorstelt zal veel processen die in een tijdloop draaien om zeep helpen. En wat doe je bijvoorbeeld met een process dat standaard loopt in het uur dat je overslaat? Of dat standaard loopt in het uur dat niet twee keer langskomt? Wat doe je met een wekker die ingesteld staat in het uur dat overgeslagen word? Wat die je met processen die connecties per uur tellen? De klok niet meer gebruiken en een eigen timer bijhouden in het proces?

Volgens mij is het dus NIET eenvoudig. Maar we beschamend voor Apple want het is zeker wel te testen. Slordig.

[MicGlou]

Ik ging uiteraard kort door de bocht, maar de boodschap is duidelijk... het juist functioneren van het platform is o.a. afhankelijk van basis functionaliteit zoals een betrouwbare klok en de daaraan gekoppelde software. Maar dit soort problemen zijn al veel ouder dan het platform iOS is en toch falen ze keer op keer... En ik blijf bij mijn standpunt, het gelijk laten lopen van een klok, ongeacht wel of geen DTS, behoort een eenvoudige taak te zijn. Jouw interessante uitleg gaat over hoe software die tijd zou moeten interpreteren... dat is toch echt iets anders dan datum en tijd 'op tijd' te laten lopen. En dan nog behoren het geen grote problemen, schedulers kunnen al jaren omgaan met het verspringen van tijden door een 'eenvoudige' als X is gemist, dan bij Z herhalen... tuurlijk weer heel summier uitgelegd, maar het zijn je basis drempels die je bij afhankelijke software behoort te tackelen... eenvoudig was misschien een verkeerde term: basic is een beter woord.

https://developer.apple.c...dTimes/DatesAndTimes.html

Ze hebben het best eenvoudig gemaakt voor iOS... wat mijn punt is, alles wordt gebaseerd vanaf een standaard klok en datum... niet veel anders dan een digitaal horloge. Die interpretatie veranderd nooit, alleen als een regio DTS/DLS aanpast... toch gaat het wederom fout... maar daar waren we het over eens

[Reactie gewijzigd door MicGlou op 24 juli 2024 22:39]

[Verwijderd]

Het woord "eenvoudig" en "tijd" horen niet in een zin. Er is niets eenvoudigs aan. Het oosten van Australia doet aan de wintertijd, maar het westen van het oosten niet, daarentegen ligt in datzelfde westen van het oosten een dorp wat er wel aan doet. Zo debiel zijn zomer- en wintertijden.

Daarentegen geef ik je gelijk dat ondanks de moeilijkheid, dit gewoon moet werken.

[mystic101]

Geen slecht idee. Dan komen we tenminste van het nutteloze DST af. Of zou de macht van Apple nog niet zover reiken?

[Avalaxy]

Huh? Het gaat er echt totaal niet om dat Apple er problemen mee heeft. Het is iets wat voor héél véél mensen moeilijk is. Ik snap je boze reactie niet echt, want dat is helemaal niet wat ik bedoel of zeg.

[Tweaker1234]

Precies, menig doet het lijken alsof het aan DST ligt en niet aan Apple die voor de tweede keer 'niet bij de tijd is'.

[Conzales]

edit:

Een workaround/tijdelijke fix is om 'automatisch' uit te zetten bij de instellingen, vervolgens een tijdzone kiezen die niet aan DST doet (india bijvoorbeeld) en dan handmatig ff de tijd goedzetten. De tijdlijn van de agenda springt weer terug naar de juiste plek.

Dat niet alleen, maar laten we maar stoppen met 'wintertijd', want dat bestaat niet. Internationaal heet het dan ook 'DST', Daylight Saving Time, wat wij zomertijd noemen.
http://www.ronaldk.nl/index.php?q=dewintertijdbestaatniet.md
Ik zou zeggen afschaffen die handel, dan zijn er ook geen problemen meer; technisch gezien en ook qua gezondheid. Zomertijd is gewoon een nachtmerrie voor de niet ochtendmens.
http://www.nietnuttig.nl/...-slecht-voor-avondmensen/
Placebo-effect of niet, ik doe er zeker 4 weken over in het voorjaar om gewend te raken aan de zomertijd.

[Reactie gewijzigd door Conzales op 24 juli 2024 22:39]

[Mizgala28]

Dus:

Nexus 4, Android 4.3, verliep probleemloos

TOSHIBA laptop met Windows 7 SP1, verliep probleemloos

Mac Mini met OSX 10.9, verliep probleemloos

Simpele Philips wekker, verliep probleemloos

iPad 3 met iOS 7, alweer gekloot.

Apple, ieder jaar kan in op al mijn genoemde apparaten vertrouwen dat ze zo’n simpele handeling probleemloos uitvoeren, zelfs osx kan het, maar iOS nog steeds niet?

Shame on you Apple

[Martinspire]

Mja vooral ook dat Windows, OSX, Linux, Android, Blackberry en Windows Phone dit soort zaken wel gewoon goed hebben, maakt dit bericht weer wat apart.

[Shark.Bait]

vergeet voor het gemak het y2k probleem van windows (en wat andere oudere systemen) en het vele geld dat daarbij gespendeerd werd het op te lossen. Datum / tijd is blijkbaar lastiger dan wij vermoeden, omdat we niet half weten hoe het achter de schermen geprogrammeerd is.

[SF750]

Indertijd speelde het probleem dat geheugen kostbaar was. Van datums werden vaak (onbekend dus hoe vaak, vandaar de grote onzekerheid toen) alleen de laatste 2 digits gebruikt. en de '19' er vast voorgezet. Zodoende kon een programma van 1999 naar 1900 'springen'.

Geheugen is allang geen probleem meer. Ben dan ook benieuwd wat de oorzaak is van deze bug.

[bArAbAtsbB]

Y2k was geen probleem van Windows....maar van de ingebouwde klok in de moederborden!! het jaartal was in 2 cijfers vastgelegd.....en met de overgang naar 00 wist men niet goed hoe alles zou reageren! (maar dit ging vooral over alle computers zonder windows....die dus geen mogelijkheid hadden tot een workaround!

[Mizgala28]

Klopt maar het is wel opgelost.

Zo ook met Android en WP, het werkt probleemloos (ook op Symbian en BB OS7 (ken niemand met 10)).

Maar van Apple had ik het beter verwacht, het is al jaren een bekend probleem bij iOS.

[xxxneoxxx]

Ja, want een issue welk misschien eens in de 100 jaar terug komt is best te vergelijken met een issue wat gegarandeerd 2 keer per jaar voorbij komt.

[Me_Giant]

Ik dacht dat het y2k probleem ook grotendeels een hoax was?

[WhatsappHack]

Voor thuisgebruikers weet ik niet of het nou echt wel zo extreem relevant was, maar tot op zekere hoogte wel natuurlijk.

Maar het was zeker een probleem omdat de computer geen idee had of 00 nou stond voor 1900 of 2000; dus dat was zeker problematisch te noemen.
In hindsight is het natuurlijk nooit bewezen omdat veel apparatuur "millenium proof" werd gemaakt... Maar ik denk dat het in dit geval "better safe than sorry" was, en dat het niet slecht was om dat te doen.

[Rembert]

Dan wil ik meer van dat soort hoaxen. Ik heb er behoorlijk wat werk aan gehad bij klanten. Over 27 jaar mogen we weer want dan springt de computerdatum naar 13 december 1901 in veel software oplossingen. Met de huidige pensioenplannen zit ik dan net tegen mijn pensioen aan denk ik. Hoop dat ik dan nog mee kan in de ICT :-)

[CyBeR]

Haha. Het y2k probleem vergelijken met iets simpels als een uur terug of vooruit... Dit is wel een van de meest foute en zwaar irrelevante bochten waar ik iemand die Apple wil verdedigen zich ooit in heb zien wringen. Het overstijgt veel belachelijke opmerkingen die ik in de jaren vanuit dat kamp heb gehoord. Petje af...!

Het Y2K-probleem is grandioos veel simpeler dan DST.

[WhatsappHack]

Mwah, dat ligt er maar net aan op welke schaal je het wilt bekijken.
Als je software in deze dagen nog steeds niet zoiets bizar simpels als een offset kan parsen, dan is er echt iets mis met je programmeurs.

Y2K was in essentie simpel, maar vergde aardig wat meer moeite om *in elk systeem* te fixen. Apple hoeft het maar in 1 simpel systeem te integreren. Dus wat dat betreft: Neuh, Y2K was absoluut niet grandioos veel simpeler dan een simpele offset van een uurtje die elke 6 maanden wijzigt.

[Ikkehans]

Hmm... geen enkel probleem mee. Ik had hem op 'vliegtuigmodus' staan vannacht, om te checken of iOS ook iets via wifi verstuurd/ontvangt om de aanpassing te doen, maar vanochtend was hij keurig aangepast.

Ook de klok in de agenda is gewoon aangepast.

[Conzales]

Het gaat om de tijdlijn in de agenda, niet de tijdweergave zelf.

[Me_Giant]

Met iOS 7 op mijn iPhone 4 heb ik inderdaad last van de verkeerde aanduiding in de agenda. Misschien toch maar weer handmatig instellen dan.

[SF750]

Grappig. Hier een 4, 5 en een iPad, allen met iOS 7. Alles is vannacht automatisch aangepast.

wat ik merkwaardig vind is dat als de systeemtijd klopt, het dan mogelijk is dat verschillende app's op hetzelfde apparaat een verkeerde tijd aangeven.

Als ik een programma schreef indertijd dan ging ik meestal uit van de systeemtijd. Nergens een time = time +1 ofzo. Inplaats van mi allen maarj te downmodden graag een zinnige reactie svp.

[Reactie gewijzigd door SF750 op 24 juli 2024 22:39]

[Ricmaniac]

Me wekker ging gewoon goed af vannochtend op de nieuwe tijd =p daar ben ik allang blij mee