Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 75 reacties, 23.353 views •

De 'niet storen'-feature die in iOS 6 zit ingebakken zal na 7 januari weer als vanouds werken, zo heeft Apple beloofd. Na de jaarwisseling bleek dat de functionaliteit, die geluiden van binnenkomende notificaties uitzet, ook buiten de ingestelde tijd geluiden dempt.

Op de site van Apple is een verklaring gepubliceerd waarin het probleem met de 'niet storen'-feature wordt erkend. De fabrikant laat weten dat Do Not Disturb buiten de ingestelde tijd blijft werken, waardoor gebruikers geluiden voor binnenkomende notificaties van bijvoorbeeld telefoongesprekken of berichten missen. Volgens Apple zal de functie na 7 januari weer normaal werken. Tot die tijd wordt geadviseerd om handmatig 'niet storen' uit te zetten. Een verklaring voor de bug werd niet gegeven.

De problemen met 'niet storen' verschenen na de jaarwisseling, toen gebruikers op verscheidene fora en sociale media lieten weten dat de functionaliteit zichzelf niet automatisch uitschakelde. De functionaliteit werd door Apple geïntroduceerd in iOS 6 en kan er bijvoorbeeld voor zorgen dat gebruikers 's nachts niet gestoord worden door geluiden van binnenkomende notificaties.

Het is niet de eerste keer dat iOS-software met problemen kampt na een jaarwisseling. Twee jaar geleden gebeurde dat ook al, toen bleek dat ingestelde wekkers niet langer functioneerden. Ook toen liet Apple weten dat de functionaliteit zichzelf zou herstellen, maar toch bleef een aantal gebruikers nog last hebben van de bug.

Reacties (75)

Reactiefilter:-175074+150+22+30
Moderatie-faq Wijzig weergave
DST (daylight saving time) is lastiger dan je denkt, kijk hier maar eens naar
http://www.youtube.com/watch?v=84aWtseb2-4

(reactie op KvanSteijn)

[Reactie gewijzigd door thalantis op 3 januari 2013 08:11]

Daarom zijn er al talloze libraries die hier wel correct mee om kunnen gaan. Mijn vermoeden is dus dat Apple het wiel opnieuw heeft uitgevonden, maar hem allen niet helemaal rond heeft gemaakt.
Geweldig interessante video. Nooit geweten dat dit zo versnipperd was... Wat mij betreft > afschaffen die handel.

Maar dit topic gaat over de jaarwisseling, en dat heeft natuurlijk niets te maken met de DST. Ook een jaarwisseling is lastig te testen, zeker onder een betatest groep die zomers bezig is, maar dit zou op zich eruit te halen moeten zijn. En het is opmerkelijk dat iOS telkens weer moeite heeft met dit soort tijddingetjes...
Idd: zal wel zwaar OT zijn maar dat hele zomer- / wintertijdgedoe is zo enorm achterhaald.

Toen de meerderheid der mensheid nog van 8 tot 5 actief was, was hier wellicht een energiebesparing te behalen. Maar aangezien we tegenwoordig van 6 uur 's ochtends tot 10 uur 's avonds actief zijn, is dit volstrekt nutteloos geworden.

Kijk nu naar deze tijd. Het is nu nog praktisch donker buiten (kwart voor 9). Als ik vanavond naar huis ga om 5 uur is het ook alweer donker. Wat is dan de besparing? Niks toch 8)7 ?

Het omzetten van die klokken (waar zoals het filmpje bewijst ook geen enkele standaard voor is), is enkel tijdrovend, irritant en kost ons alleen maar geld (verloren tijd door instellen, vergissingen en de - weer ontopic - onvermijdelijke bugs in allerlei software).
De besparing zit in de zomertijd niet in de winter ;) Want de winter tijd is de echte tijd.

Eerlijk gezegt ben ik juist voorstander van de zomertijd, want heb ik zelf meer aan een uurtje extra licht in de avond dan dat het al om 5 uur licht is want dan lig ik toch in mijn bed. En daarvoor wil ik best 2 keer per jaar 1 minuut besteden aan het verzetten van 2 klokken in huis, de rest gaat toch automatisch. Het enige wat ik me zou kunnen indcenken is dat het makkelijker zou zijn om die data gelijk te trekken over de gehele wereld.

Je bespaart dus door dat je in de zomer het licht een uur later aan kan doen.
Inderdaad, het is nu vooral voor de boeren en andere mensen die buiten werken. Maar ik zie ook niet helemaal in waarom die niet gewoon hun werktijden aanpassen, dan kunnen ze het ook wat flexibeler doen (bijv. per half uur). Maar het is tegenwoordig Europees bepaald dus ik zie ze dat niet zo 1-2-3 aanpassen.

[Reactie gewijzigd door GekkePrutser op 3 januari 2013 10:13]

Hoeveel tweakers heb je nodig om een dag en tijd uit te rekenen? ;)

Als ik er als ontwikkelaar naar kijk constateer ik het volgende: Uitvinden wanneer een wekker af moet gaan of een timer aan of uit, behoort niet tot de categorie rakettechnologie. Toch is dit iets waar Apple wel heel vaak mee worstelt. Het jaar 2013 is geen bijzonder jaar. Het is geen schrikkeljaar. Het is geen priemgetal. Mijn wekker heeft nog nooit een dag overgeslagen. Mijn alarmsysteem met timers heeft nog nooit een timer moment gemist.

Mogelijke oorzaak 1: te weinig Separation Of Concern in iOS. Waarom moet de wekker uitzoeken hoe laat het is? De tijd wordt bepaald door de tijd service in het OS. Een timer service kan op afgesproken momenten een event af te laten gaan. De wekker zoekt dus niet uit hoe laat ie af moet gaan. De Do not disturb hoeft op de zelfde manier niet te bepalen hoe laat het is.

Mogelijke oorzaak 2: het OS zodanig een zooitje is dat ontwikkelaars niet meer weten welke calls ze moeten doen om uit te vinden hoe laat het is.

Mogelijke oorzaak 3: ontwikkelaars zijn met van alles bezig, maar niet de goede dingen. Managers kijken alleen of het er goed uitziet.

Alle mogelijke oorzaken zijn wat mij betreft even zorgelijk,
@TheWim: Mijns inziens is jouw houding exact waarom het zo vaak mis gaat met datum en tijd berekeningen. Mensen (en dus developers) denken ten onrechte dat het heel makkelijk is en maken dus allemaal fouten.

Als je denkt dat het makkelijk is kun je er donder op zeggen dat je code buggy is.

Er zijn legio voorbeelden van fouten met data en tijd, juist omdat het vol zit met complexe patronen, vreemde uitzonderingen, verschuivende tijdzones, zomer- en wintertijd veranderingen (zoek voor de lol eens op in welke tijdzone Arizona ligt) en obscure regels. Van het Y2K probleem tot Android die pasgeleden de hele maand december miste tot dit probleem. Het komt erg vaak voor.

Ik denk dat als je developers zou vragen om een stukje code te schrijven dat bepaalt of iets een schrikkeljaar is zonder dat ze informatie er over mogen opzoeken, 90% het fout doet. De meeste mensen denken dat ieder jaar deelbaar door 4 maar niet door 100 een schrikkeljaar is en gaan daarmee meteen de mist in.

Net als bij iets complex als cryptografie wordt er bij datum en tijd berekening altijd aangeraden zoveel mogelijk bestaande en beproefde libraries te gebruiken om bugs te vermijden.

[Reactie gewijzigd door Maurits van Baerle op 3 januari 2013 12:38]

(en ook @jabwd) Zou kunnen, maar leg mij dan maar eens uit waarom de wekker geen last heeft van het probleem en de Do Not Disturb wel. Wat mij opviel is dat ze geen van beide last mogen hebben van de bug, of allebei wel. Blijkbaar is er een verschillende manier om tegen tijd/timers aan te kijken in beide applicaties. Hieruit trek ik mijn mogelijke conclusies.
Je hele reactie zit vol met conclusies die nergens op gebaseerd zijn. Je weet niet hoe de code er uit ziet, je weet niet hoe ze werken bij apple en je weet ook al helemaal niet hoe do not disturb werkt. Date & Time berekeningen zijn altijd lastig en fouten kunnen hier gewoon in kruipen, als jij hier nooit problemen mee hebt gehad is het heel erg goed mogelijk dat je code fout is en alleen werkt op bepaalde data ( wat vaak het geval is bij de meeste ontwikkelaars ), of de andere 'mogelijke oorzaak' dat je gewoon extreem onervaren bent. Als het nummer 86400 je bekent voor komt heb ik slecht nieuws voor je..

Er is een heel er goede reden waarom er zo verschrikkelijk veel API's beschikbaar zijn voor date & time, als het zo simpel was zou dat ook niet nodig zijn.

En natuurlijk neemt dit helemaal niet weg dat z'n fout niet echt moet gebeuren, maar bugs zijn er nou eenmaal en er staat zelfs een icoontje in je menubalk als do not disturb aan staat…

[Reactie gewijzigd door jabwd op 3 januari 2013 12:37]

Foutje moet kunnen, maar dat preserverende gedrag van Apple vind ik maar niets. Waarom kunnen ze de fout wel erkennen, maar niet uitleggen wat er mis gaat? Ze weten wat er is en dat het zichzelf oplost, maar kiezen ervoor geen uitleg te geven. Waarom moeten ze blijven doen alsof hun producten een soort magische wezentjes zijn? Ik heb nu bijvoorbeeld geen flauw idee of er een onzichtbare ongevraagde update gepusht wordt of dat het een probleem is dat zichzelf echt oplost.
Wel beetje makkelijke weg zeg. Ondanks dat er een work-around schijnbaar is lijk me toch allerminst dat je zulke problemen oplost. Ik zag al inderdaad dat een aantal hier de datum naar 7 januari verplaatst dat die het niet meer doet. Probleem kan ik ongeveer weg gokken...deze week is week 53/week 01, bij oa opvragen via PHP met date("Y") krijg je 2012 ipv 2013. Door gebruik te maken van unix tijd date("o") krijg je wel de correcte jaar. Liep er vorige week tegenaan :+

Terugkomend op de reactie van Apple, mijn klanten zouden het niet accepteren als ik zou zeggen, wacht maar even een weekje dan doet alles het weer...
Terugkomend op de reactie van Apple, mijn klanten zouden het niet accepteren als ik zou zeggen, wacht maar even een weekje dan doet alles het weer...
Overdrijven is ook een vak... Die bug is zo levensbedreigend en noodzakelijk dat jouw klanten geen 4 dagen zouden kunnen wachten? Hoelang denk je dat het duurt om een bugfix te maken, testen en distribueren aan miljoenen toestellen?
Terugkomend op de reactie van Apple, mijn klanten zouden het niet accepteren als ik zou zeggen, wacht maar even een weekje dan doet alles het weer...
Als mijn software draaide op miljoenen devices over de hele wereld, dan zouden mijn klanten het niet accepteren als ik overhaast een fix de deur uit doe, die onmogelijk binnen een week uitvoerig getest kan zijn.

Als ze de bug hebben achterhaald, en hebben gezien dat het zichzelf oplost binnen een x aantal dagen, dan heeft het gewoon geen zin om een update te ontwikkelen, volledig te regressie-testen en uit te rollen, als die automatische oplossing toch eerder gaat zijn.
Het punt is dat niet 'alles' stuk is, maar een functie waar mensen prima zonder mee kunnen. Neemt niet weg dat het erg slordig is, en natuurlijk niet had mogen gebeuren. Maar goed, dates en programmatuur zijn altijd een apart verhaal, zou inderdaad goed te maken kunnen hebben met week 1.
Maar zo te zien is jouw bug server-side op te lossen en heeft dat geen betrekking op een fix verspreiden over miljoenen devices. Een proces dat waarschijnlijk net zo lang duurt als gewoon 4 dagen uitzitten.

Begrijp me niet verkeerd, het is slordig. Maar geef toe; is het nou ťcht zo'n kritieke feature?

Daarbij kan een gevestigd multinational als Apple deze 'arrogante' houding gewoon aannemen natuurlijk, daar ze genoeg in reserve hebben en ze dit waarschijnlijk niet eens een cent zal schelen.

[Reactie gewijzigd door jfversluis op 3 januari 2013 08:58]

De bug die ik benoem is inderdaad in mijn geval server side. Echter probeer ik voor mensen enigszinds te beschrijven wat er mis kan gaan. Uit eindelijk maakt het geen bal uit of ik nou op een server zit op een device, ze hebben allemaal dates...

Ik denk dat het niet aan mij is om het kritiek te beschouwen. Zelf heb ik geen iPhone dus kan er weinig over zeggen. Wat ik wel kritiek vind, al is het voor een paar dagen is:

De fabrikant laat weten dat Do Not Disturb buiten de ingestelde tijd blijft werken, waardoor gebruikers geluiden voor binnenkomende notificaties van bijvoorbeeld telefoongesprekken of berichten missen.

Stel je hebt een bedrijfstelefoon, en in het slechtste geval stond die voor een gehele dag in die stand (ingesteld), heb je dus de gehele dag geen telefoontjes of berichten die je hoort. Dat zou ik niet willen als ondernemer...zelfs niet als het iedere dag tussen een klein tijdsmoment is...

En inderdaad multinational met arrogante houding, worden ze uiteindelijk nog wel een keer op afgerekend.
Ik wil geen eindeloze discussie aanzwengelen, echter gaat het inderdaad om data. Dat maakt niet uit server-side of client-side, echter het uitrollen; de logistiek en (eventuele) impact hiervan is compleet verschillend.

Ik kan me dan goed voorstellen dat je de afweging maakt om je in dat proces te storten of mensen te adviseren even af te wachten en de functie een paar dagen uit te schakelen/handmatig te bedienen.

Als ondernemer zou ik je niet erg slim vinden als jij je telefoon overdag op de DnD stand zet ;) dan is het nogal wiedes dat je dingen gaat missen. Daarnaast zijn er volgens mij maar weinig mensen die toch niet tussentijds even hun iPhone een keer aandrukken om te kijken of ze toch per ongeluk wat hebben gemist.

Daarboven op omhelst de functie ook nog een escape waarbij bepaalde contactpersonen altijd doorkomen en herhaaldelijke oproepen ook doorkomen. Ik kan me ook haast niet voorstellen dat veel mensen dat uitzetten. Met andere woorden; kritieke telefoontjes kun je haast niet missen.

Ik denk niet dat ze hier heel hard op worden afgerekend. Nogmaals; het is slordig, maar volgens mij niet kritiek en ik kan de afweging om gewoon af te wachten heel goed begrijpen.
Het is ook gewoon super lastig om met alles rekening mee te houden als het om tijd gaat. Wintertijd, zomertijd enzovoort!
Unix time is a single signed integer number which increments every second, without requiring the calculations to determine year, month, day of month, hour and minute required for intelligibility to humans.
Bron: http://en.wikipedia.org/wiki/Unix_time

Je kunt het zo moeilijk maken als je zelf wilt ;)
LOL, dat zijn inderdaad wel de moeilijkste dingen bij software ontwikkeling :p
Ik ken de functionaliteit niet, maar ik neem aan dat je gewoon per dag kun instellen hoelaat het an en uit moet. Wat maakt dan de zomertijd, uur tijdsverschil, schikkeljaar e.d. uit? Je kunt toch gewoon de tijd uitlezen, die is elke dag hetzelfde en als het moment passeert zetj e de functionaliteit aan of uit.

Ik heb het idee dat er veel code wordt geschreven die volledig zinloos is. Allemaal onnodige complexiteit. Hetzelfde als met die wekker bug, waarom zou je met alle mogelijke variabelen rekening houden als de wekker om 8uur moet afgaan. Kwestie van checken of het 8uur is, indien ja, wekker aflaten lopen (maar misschien ben ik te simpel :) )
Misschien omdat Apple geen vacature had open staan voor klok-specialist.

Lekker simpel om elk argument zo weg te blazen trouwens. Ow jij hebt commentaar op merk X, nou waarom werk je er niet als je het zo goed weet, en hoppa discussie naar de kloten...
De hardware moet uit de wake komen, hierdoor moet men van te voren aangeven over hoeveel uur je toestel moet ontwaken.

Als hierbij geen rekening wordt gehouden met zomer/winter tijd, wordt jou telefoon te vroeg of te laat ontwaakt en zal hij falen.

Tuurlijk kan je je device ook de hele tijd laten pollen
while(true)
if(wekkerTijd > huidigeTijd)
ga af

Maar dat lijkt mij niet de meest goedkope oplossing (batterij enzo, je mobiel blijft dan actief).
@Carino: Requires data connection
@Blokker_1999: Als iemand mij belt moet mijn telefoon ook uit de idle stand komen, dus nee, tuurlijk doet hij dingen op de achtergrond.

[Reactie gewijzigd door XiniX88 op 3 januari 2013 08:48]

de meest eenvoudige oplossing hierin zal Apple's eigen Push notificatie systeem zijn... Enige wat je hoeft te doen is een nieuw bericht type in het leven te roepen die nooit zichtbaar zal worden maar wel applicaties (of enkel het toestel) even wakker kunnen maken... dan heb je verder geen enkele logica op de telefoon nodig.

probleem is dan echter wel dat een bericht gemist kan worden en dan krijg je selectief niet goed werkende software...
Tuurlijk kan je je device ook de hele tijd laten pollen
while(true)
if(wekkerTijd > huidigeTijd)
ga af
Of ik nou met iemand afspreek over 5 uur of om 14:30 in beide gevallen moet ik klok kijken om te zien of het tijd is om in actie te komen...

Oftewel je moet hoe dan ook pollen of zelf tellen, dat systeem kan nooit magisch weten dat er ineens 5 uur voorbij is gegaan...
Elk modern RealtimeClock IC kan gewoon een simpele IRQ doen om een van te voren geprogrammeerde tijd, zo moeilijk is dat nou ook weer niet.
De hardware moet uit de wake komen, hierdoor moet men van te voren aangeven over hoeveel uur je toestel moet ontwaken.
...en daarvoor heb je als ik het zo zie geen datum nodig. Alleen de dag van de week en de tijd. Dat is volledig onafhankelijk van schrikkeljaren, zomer- en wintertijd en wat al niet. Ik heb het vermoeden dat Apple ergens toch iets met de datum doet en dat het daar fout gaat. Waarschijnlijk iets met een weeknummer ofzo, aangezien het de 7e (eerste volledige week van het jaar) opgelost is ;)
ware het niet dat zomer/wintertijd toch echt maanden verwijderd ligt van 1 januari..
Dit probleem heeft niets te maken met zomer/winter tijd.

Een degelijke implementatie is bestand tegen jaarwisselingen, dwz ziet niet eens welk jaar het is voor timer afhandelingen en zo.

Voor eventuele taken schedule je een wakeup na bv 'x' seconden (waar bij x afhankelijk is van de 1e taak die je moet doen). Na het uitvoeren ga je weer in sleep, waarbij je eventueel een nieuwe wakeup instelt voor een volgende taak.

Hoewel het niet duidelijk is of het te maken heeft met een eerder probleem is het wel verdacht dat het weer op eenzelfde moment optreed.
Je denkt nu toch niet dat wanneer je telefoon in standby staat dat deze helemaal geen dataverwerking meer doet mag ik hopen. De CPU blijft gewoon op laag tempo werken en de achtergrondprocessen blijven netjes hun ding doen. De applicatie moet gewoon op bepaalde intervallen kijken of er actie ondernomen moet worden en als de tijd gekomen is alles doen om die actie ook te laten uitvoeren. Er moet helemaal van te voren niet gekeken worden hoe lang het nog moet duren.
Eigenlijk, blijft de baseband chip draaien, deze zeer energie zuinige chip word ingezet voor push tel sms etc. en zelfs geofencing, zelfde geld voor muziek, enkel de decoder AIO chip blijft aanstaan en daarom is het mogelijk zo lang muziek te luisteren op je device.

Dat is ook het mooie van het iOS framework, je kan je applicatie niet in de achtergrond laten draaien ze worden altijd gesloten, alleen apple heeft API's geschreven voor die decoder chip en baseband chip etc waardoor het mogelijk is dat de app muziek blijft spelen in de achtergrond zonder daadwerkelijk cpu kracht te verslinden
het bereik kan soms toch weg vallen... dan kan je nog zo'n goede data verbinding hebben, push wordt dan gewoon niet ontvangen.

uiteraard kan het allemaal netjes met achtergrondprocessen etc, maar het zal me niks verbazen als ze voor een centraal beheerde oplossing gekozen hebben...
Ik denk dat je je daarin vergist. Ongeacht hoe de telefoon werkt in standby modus of do not disturb mode is het vrijwel zeker dat er een timer gebruikt wordt die voor de volle periode ingesteld worden. Die zijn veel efficiŽnter dan iedere minuut een timer af te laten gaan en dan kijken hoe laat het is en of de do not disturb mode uitgeschakeld hoeft te worden. Dat is dan iedere minuut verspilde CPU en compleet nutteloos omdat je al exact weet wanneer de handeling uitgevoerd moet worden.

Jij zet 's avonds ook niet de wekker om je de hele nacht door iedere minuut wakker te maken zodat je iedere minuut kan bepalen of je al op moet staan. Die stel je in om af te gaan wanneer je op moet staan want dat weet je van te voren al.
Hoe weet die timer dan dat er X uur verstreken is? ;) exact er is een mechanisme dat om de zoveel tijd 'alarm aangezet + interval >= tijd nu' uitrekent :)
Er is een algoritme die de systeemklok moet bijhouden. Waarschijnlijk kan in dat algoritme een event worden gekoppeld aan een bepaalde tijd. Dat is dus veel efficiŽnter dan dat je zelf een while loop programmeert. Een while loop gooit je CPU verbruik omhoog en slurpt daarmee je batterij leeg. De body van de while loop wordt afhankelijk van de beschikbare processorkracht honderden malen uitgevoerd binnen een seconde, terwijl het systeemklokalgoritme slechts eenmaal per seconde controleert of het tijd is om het event te triggeren.

Daarbij is het verstandiger om vooraf de formule 'alarm aangezet + interval' te berekenen omdat je dan uiteindelijk alleen nog maar hoeft te controleren of de huidige tijd gelijk is aan de alarm tijd, scheelt weer wat ALU gebruik.
Maakt niet uit of het "super lastig is". Het moet gewoon werken. Wat heb ik aan een telefoon die niet overgaat als je gebeld wordt?

Als het te "super lastig is" moeten ze het niet vrijgeven. Aan halfwerkende functies hebben we niets.
Stel je niet aan halfwerkende functies, werkt prima zit alleen een bug in van een week.
Als iedereen zo kieskeurig is zouden er een stuk minder mobieltjes verkocht worden van de concurent.
Een functie die een week per jaar niet werkt is inderdaad een 'halfwerkende functie'. Als het op het favoriete merk aankomt van een fanboy is blijkbaar alles geoorloofd...
Voor een super groot bedrijf met super veel resources denk ik dat dit probleem een eitje moet zijn. Dit geldt niet alleen voor Apple overigens.
Een supergroot bedrijf als Apple heeft zoveel resources/werknemers omdat ze nogal veel werk te verzetten hebben.
Het is niet zo dat er een paar honderd werknemers zitten te wachten op werk en dat ze, zodra er een bug gemeld wordt, erop kunnen springen.
Natuurlijk zijn er afdelingen welke continu aan het monitoren zijn of er kritische bugs gemeld worden, maar laten we eerlijk zijn, dat is deze niet.
Als ik een iPhone-bezitter zou zijn, zou ik hier niet echt wakker van liggen.
Maar ik vind het ook niet erg om een gesprek te missen, mijn telefoon staat eigenlijk altijd op stil.
De producten bij Apple zijn in verhouding tot de omzet en winst erg gelimiteerd dus jouw reactie slaat behoorlijk de plank mis.
In je op een na laatste zin zit wel een leuke pun.
Als in eiPhone bedoel je? ;)
(...) Wintertijd, zomertijd enzovoort!
Volgens mij ging de klok niet vooruit of achteruit rond oud en nieuw. Als de wekker nu 0x of 2x afgaat bij zomer (er is geen 2:30) of wintertijd (er is 2x 2:30), dan kan ik me nog enigsinds een 'lastige' uitdaging indenken...
Volgens mij ging de klok niet vooruit of achteruit rond oud en nieuw.
Nee, maar de dag en maand wel. Na 31 december komt 1 januari. Als er geen jaartal bij staat, gaat de kalender dus achteruit.

Als de code ongeveer werkt als "als de eindtijd eerder is dan de begintijd, is de eindtijd in de volgende dag", en "de volgende dag = huidige dag +1", maar in dat laatste stukje wordt geen rekening gehouden met dat 1 januari na 31 december komt, dan hang je.

Het zou slordig zijn, maar als je programmeert moet je aan alles denken, want uit zichzelf gebeurt er niets. Als er niet met een bepaald scenario rekening wordt gehouden (bijvoorbeeld een jaarwisseling), dan krijg je dit soort bugs.
Nee, maar de dag en maand wel. Na 31 december komt 1 januari. Als er geen jaartal bij staat, gaat de kalender dus achteruit.

(...)

Het zou slordig zijn, maar als je programmeert moet je aan alles denken, want uit zichzelf gebeurt er niets. Als er niet met een bepaald scenario rekening wordt gehouden (bijvoorbeeld een jaarwisseling), dan krijg je dit soort bugs.
Ik vind het echt leuk dat je het uitlegt, maar volgens mij in mijn voorbeeld van 0x of 2x een 2:30 op dezelfde dag wel aan dat ik het probleem begrijp, gaat je wekker 0x of 2x af om 2:30? Als je zo nog programmert zonder jaartal, dan ben je een IT-er van NA het millennium-probleem dan. Hoe ongelovelijk klasiek is dŠt wel niet geweest.

Apple hing ook al eerder op een uurtje tijdverschil met de wekker, volgens mij is er wat mis in hun tijd/datum objecten, als ze uberhaupt al code hergebruiken.
Tja, dat zou een stomme fout zijn. Maar het verklaard niet waarom hij vanaf 7 januari weer werkt. Want 2 januari > 1 janurari. Dan moet het probleem toch al "weg" zijn?

En waarom zou dit met dagen werken? Je kan toch om uur X op stil gaan en uur Y weer uit die modus, onafhankelijk van de dag?
Hij werkt ook nog met weeknummers?
Maar je mag verwachten dat een beetje programmeur zo'n achterlijke fout (geen rekening houden met jaartal of schrikkeljaar) toch echt niet maakt zeker niet als je bezig bent met een applicatie die draait om datum en tijden (als je nou echt nooit ermee te maken hebt en toevallig op 1 klein plekje ineens iets met datum moet doen, kan ik me nog wel er iets bij voorstellen, maar niet als je bezig bent met een applicatie die datum/tijd gebaseerd is.)
Zomertijd/wintertijd is niks anders dan een verandering in tijdzone. De klok veranderd niet. Wat lastiger is zijn schrikkeldagen en -seconden. Vooral de schrikkelseconde is lastig, want die is niet algoritmisch bepaald.
Gezien het probleem zich op 31 december voordeed zou het best een incorrecte schrikkelseconde geweest kunnen zijn.
zomertijd/wintertijd is wel even iets meer dan alleen een verandering in tijdzone.. schrikkeldagen is ook niet echt een probleem, maar ik ben het wel eens met je mbt die schrikkelseconde..
zomertijd/wintertijd is wel even iets meer dan alleen een verandering in tijdzone.
Iets meer als in: op dag X op Y uur moet de tijdzone veranderd worden naar Z. Veel meer dan dat mag het absoluut niet zijn, anders doe je het echt verkeerd. Het is namelijk alleen de weergave van tijd, en niet een verandering van de tijd.
Tijdzone kan namelijk op willekeurige momenten veranderen, de systeem klok zal gewoon door moeten tellen en niet opeens een uur moeten verspringen. Sterker nog, systeem klok mag alleen vooruit gaan, en absoluut niet achteruit omdat tijdsberekingen dat negatieve getallen opleveren terwijl de tijd echt niet achteruit gegaan is. Om deze reden zal een goede NTP client secondes versnellen of vertragen om de tijd te corrigieren.

[Reactie gewijzigd door elmuerte op 3 januari 2013 11:25]

Dat vind ik flauwekul.

Als programmeur wordt je verwacht 'superlastige' problemen op te lossen, anders had iedereen wel kunnen programmeren. Daarnaast heeft het niks te maken met zomer/wintertijd, gezien we midden in de wintertijd zitten. Ik ben overigens zelf ook programmeur.

Begrijp me niet verkeerd, de bug bij Google wat betreft de missende December van pasgeleden is net zo prutserig.

Zo'n dingen komen gewoon voor omdat er ontzettend veel druk ligt op het team om zoveel mogelijk features erin te bouwen, met harde release dates. Bugs zijn onvermijdelijk, maar dit zijn wel grote flaters als je het mij vraagt.

Dat gezegd hebbende: Apple's reactie is logisch, de bug gaat vanzelf weg. Dat lijkt lui, maar het is natuurlijk niet makkelijk of nuttig om voor die tijd nog een fix te releasen. Het duurt enkele dagen voordat je je code volledig getest hebt, dan nog eens enkele dagen voordat je de update kunt verspreiden.
"Zo'n dingen"
Voorheen zag ik walgelijke zinsconstructies eigenlijk alleen bij Limburgers, maar ik zie het tegenwoordig steeds vaker voorbij komen.

Ben ik nou de enige die "Zo'n dingen" echt NIET vind kunnen en het ronduit onsmakelijk Nederlands vind?
Helemaal mee eens. Ik zou tegen de iPhone-bezitters willen zeggen: geniet van je rust de komende dagen.
No pun intended.

Op dit item kan niet meer gereageerd worden.



LG G4 Battlefield Hardline Samsung Galaxy S6 Edge Microsoft Windows 10 Samsung Galaxy S6 HTC One (M9) Grand Theft Auto V Apple iPad Air 2

© 1998 - 2015 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True