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 , , reacties: 331, views: 95.591 •
Submitter: Erulezz

Een bug in iOS zorgde ervoor dat gebruikers die een alarm voor 1 of 2 januari instelden, niet werden gewekt. De ingestelde alarmen gingen niet af. Gebruikers die een zichzelf herhalend alarm hadden ingesteld, ondervonden geen problemen.

HaanDe problemen werden als eerste gemeld door Engadget. Op Twitter beklagen veel gebruikers zich over de weigerende wekfunctie en ook op GoT schrijven enkele gebruikers over de bug, die ervoor zorgde dat een ingestelde wekker niet afging.

Het probleem deed zich alleen voor bij alarmen die specifiek voor 1 of 2 januari waren ingesteld; een zichzelf herhalende wekker ging wel af. De bug doet zich in ieder geval voor in versies 4.02, 4.1 en 4.2.1 van iOS.

Het is niet bekend waardoor de problemen werden veroorzaakt. Op 3 januari zou de wekfunctie weer werken als vanouds. De falende wekfunctie doet denken aan een gelijksoortig probleem in november, bij de overgang van de zomertijd naar de wintertijd. Toen weigerden juist de zichzelf herhalende wekkers dienst.

Reacties (331)

Reactiefilter:-13310299+1128+24+30
1 2 3 ... 10
Haha, bij Apple hebben ze geen zin om in het nieuwjaarsweekend vroeg op te staan :)
En aangezien Apple zijn klanten wel meer oplegt kon dit er ook nog wel bij :*)

Toch ben ik wel benieuwd hoe dit nou komt, in mijn herrinnering is het beduidend moeilijker om een kalender te schrijven die fout is dan een die goed werkt.

_/-\o_ aan de ontwerper van deze functionaliteit _/-\o_
Zal iets te maken hebben met dat op maandag 3 januari pas de eerste week van 2011 begint. We zitten nu nog in week 53 van 2010.

Neemt niet weg dat het een erg domme bug is, waar Apple bovendien ook nog van op de hoogte was.
We zitten nu nog in week 53 van 2010.
Week 52
* sharky_ zal wel uitspraak doen in deze case:

Het is week 1 van 2011 maar die is begonnen in 2010. Lijkt me dat het dan eigenlijk week 53 van 2010 is en frickY gelijk heeft.

case closed.
Volgens ISO 8601 en NEN 2772 is de eerste week van een jaar de week die vier of meer dagen van dat bewuste jaar bevat. Omdat, volgens NEN 2772, de eerste dag van de week een maandag is, komt het erop neer dat week 1 de week is, waarin de eerste donderdag van dat jaar zit of de week waar 4 januari in valt.
Voor de duidelijkheid: Dit wil zeggen dat het nu week 52 van 2010 is. Een week 53 komt niet zo heel vaak voor, in 2009 hadden we een week 53, de volgende is in 2015 en die daarna in 2020.
En wie zegt dat Apple tijdens het programmeren rekening houdt met ISO normen?
Dat doen de onderliggende unix systemen wel voor ze, en waarschijnlijk is het niet rekening houden daarmee juist de oorzaak. Ik zag op GoT iemand die tot 3 januari exact hetzelfde probleem ging hebben en daar op 1 januari achter kwam. Hij heeft 't alleen wat sneller kunnen fixen bij gebrek aan 400 miljoen devices in the field.
Dat mag je toch wel hopen.
In de VS is de week waarin 1 januari voorkomt altijd de eerste "week" van het jaar maar dan verkort tot 2 dagen in 2011, 3 januari is alweer week 2. Daar zal het probleem mee te maken hebben.

Zie kalender 2011:
http://annystudio.com/calendars/2011/2011weeks.gif
4x91 ook. Vandaar eens in de vier jaar een kans op een schrikkeldag. Maar dat heeft weinig te maken met het wekkerprobleem van nu.

Raar is het wel. Ik wil op 1 januari om 11.00 uur op. Wat maakt het dan uit wat voor dag, week of temperatuur het is.
Een jaar heeft 365 dagen, dus dit is nog week 53, niet week 52, daar reageerde mad_max234 op.
Nee, de zaterdag en zondag horen nog bij week 52 van het vorige jaar. Maandag begint week 01.

[Reactie gewijzigd door doekoe2k5 op 3 januari 2011 00:20]

Een week heeft 7 dagen. Als week 1 en week 52 niet op elkaar aansluiten, is er dus sprake van een week 53. Doordat niet elk land volgt de iso normen die bepalen wanneer een week begint volgt (De week begint op zondag/maandag. Als 1 januari in de week valt is het week 1, of moet de hele week of mer dan de helft in het nieuwe jaar liggen. Zomaar wat verschillen die op kunnen treden) kan je dus niet stellen dat Maandag week 1 begint. Dat hangt sterk af van het land waar je bent.
Maar welke prutsert maakt er nu een "eenmalige" wekker die zich iets van het weeknummer aantrekt?
Mensen met een onregelmatig patroon? Alle studenten en leerlingen zo'n beetje.
Het gaat kidde om de programmeur. Waarom zou je een wekker die op een bepaalde datum moet afgaan zo programmeren dat je iets met het weeknummer van doen hebt.
Wat Kidde bedoelt is dat als het weeknummer de fout veroorzaakt, dan is het raar dat de fout juist optreedt bij een alarm dat voor 1 specifieke datum is ingesteld. Er is geen enkele reden waarom een alarm ingesteld op 1 of 2 januari zich iets zou moeten aantrekken van het weeknummer. Bij een repeterend alarm zou je dat juist eerder verwachten.
Ik ken de meeste programmeer talent niet, maar de tijd/datum constructie functie in php ( date(); ) bijvoorbeeld kan er gebruik gemaakt worden van:

"ISO-8601 year number. This has the same value as Y, except that if the ISO week number (W) belongs to the previous or next year, that year is used instead."

Het zou heel erg knullig zijn om iets dergelijks te gebruiken, maar het is niet onmogenlijk.
Apple legt zijn klanten helemaal niks op. Je hoeft je computer bijvoorbeeld niet binnen 30 dagen te activeren om dat je anders buitengesloten wordt.

Uiteindelijk leggen bedrijven hun klanten helemaal niks op, de overheid is het apparaat dat burgers iets kan opleggen, en daar is dan ook alles mee gezegd.

Als je het niet eens bent met een bedrijf of product ben je niet verplicht het nog steeds te gebruiken, flamer.
Wel, ja en nee... Apple kan je inderdaad niet dwingen om iets te doen, want je kan nog altijd naar de concurrentie lopen. Wat ze wel kunnen (en doen), is controle uitoefenen op wat de gebruiker met hun product doet of kan doen.

Het is door Apple dat je geen Flash op je iPhone/iPad kan gebruiken, het is door Apple dat je iTunes MOET gebruiken om bv. een iPad te activeren, het is door Apple dat je de App Store moet gebruiken om apps op je iOS-apparaat te krijgen etc. Of je met deze werkwijze akkoord gaat, beslis je uiteraard op het moment dat je een Apple-product koopt, of net niet koopt. Voor mij is het dit laatste ;)

Dat is iets waar Microsoft jaren totaal het tegenovergestelde in was. Je kocht iets van Microsoft en je kon er bij wijze van spreken mee doen wat je wou. Maar door het recente succesverhaal van Apple proberen ze bij Microsoft net hetzelfde te doen (closed Xbox360, closed Windows Phone 7, etc.). Op veel vlakken hanteert Google nu de werkwijze van het oude Microsoft.
Er is in de appstore anders gewoon een browser waar je flash mee kunt bekijken.
Dat Apple het zelf niet wil ondersteunen, is hun keuze.
Ik kan op m'n Windows pc ook geen .rar of .xls openen zonder 3rd party software...
Ik denk dat er bedoeld wordt dat Apple somige progamatuur niet toestaat. Zoals Flash op de iPhone/iPad/iPod touch.

Altans ze vragen webbouwers nu om in HTML5 te programmeren en zorgen voor video e.d. in HTML5 format.

Moet zeggen. Flash filmpje openen op zowel windows als op OS X vreet batterij. Als ik een HTML5 film kijk dan gaat mn battrij stuk langer mee.

Het is aan Apple om te beslissen wat zij wel en niet ondersteunen net als MS. Ben je het er niet mee eens ga je naar een ander platform.

Bug in de wekker functie is wel een indeuk in de image van Apple 2e keer binnen een Jaar dat er een vrij vervelende bug zit in de wekkerfunctie.
helaas is flash niet alleen video, games, ads, menu etc
Je kan je iPhone of iPad ook in de winkel laten activeren, dus daarvoor zal je geen iTunes nodig hebben. Dat gemekker over iTunes elke keer begint sowieso een beetje oud te worden, als je kijkt hoeveel verschillende functies iTunes voor iOS aanbiedt dan is het niet meer dan logisch dat het het enige programma is waar je dat allemaal mee kan doen, zo werkt het bij andere fabrikanten ook, hoewel die meestal niet meer aanbieden dan firmware update en bestandjes heen en weer kopieren, en vaak nog met erbarmelijk slechte software ook. Zal er wel weer een hele stroom Android fans willen reageren dat je ook applicatie x voor dit, y voor dat, z voor zus en xyz voor zo kunt gebruiken, maar dat is natuurlijk niet wat normale mensen met hun telefoon willen doen, die willen gewoon alles vanuit 1 applicatie kunnen beheren want dat is simpelweg veel eenvoudiger. Ben je echt allergisch voor iTunes dan kan je je telefoon gewoon jailbreaken en bestanden en muziek via allerhande andere tools heen en weer kopieren.
dat je gewoon foto's, muziek en filmbestanden op een telefoon moet kunnen zetten dmv usb storage is geen bizarre eis van applicatie xyz, dat hoort gewoon op alle OS'en te werken onafhankelijk van genstalleerde programmatuur.
Tsja blijkbaar voor jou erg belangrijk, ik vind het totaal niet interessant en zelfs veel te gemakkelijk van de fabrikant, om het bestandsbeheer aan de gebruiker over te laten en op die manier het gebruik van allerlei soorten metadata onmogelijk te maken. Muziek die je met iTunes naar een iOS device pushed bevat allerlei data zoals rating, hoe vaak afgespeeld, album art (ok kan ook in ID3 tag maar dat heeft ook weer zijn nadelen), playlists, etc. Voor foto's etc. geldt hetzelfde, daar zit informatie over foto-albums in, bij de iBooks informatie over bladwijzers, waar je gebleven was in het boek, enzovoorts. Daarbij maakt iTunes het kinderlijk eenvoudig om content te kopen, syncen naar verschillende devices, backuppen, automatisch transcoden om ruimte te besparen bij het syncen, en ga zo maar door.

Een apparaat dat zich gewoon als USB mass storage device registreert en waar je vervolgens zelf maar bestandjes naartoe moet slepen vind ik veel beperkter, en schopt het beheer van al die metadata en backups/sync informatie compleet in de war, waardoor het er uiteindelijk op neerkomt dat je zelf actief aan bestandsbeheer moet gaan doen, wat bij meerdere devices zelfs nog irritanter wordt. Dan gebruik ik toch echt liever gewoon iTunes, ik zie ook niet zo goed wat het probleem is.

Hoe dan ook, als je er toch liever bewust voor kiest om moeilijk te doen waar het ook makkelijk kan, kan je je iPod of iPhone dus ook gewoon zo gebruiken als jij dat blijkbaar wil, er zijn verschillende programma's die gewoon rechtstreeks bij de content op iOS devices kunnen (ik gebruik zelf incidenteel rhythmbox op linux op het werk, omdat ik daar geen iTunes kan gebruiken), en als je je toestel jailbreaked kan je zelfs gewoon via filemanagers overal bij. Als je dat zou willen dus, wat ik me nog steeds slecht voor kan stellen.
Dat is als een tankstation waar ze je door een kunstgalerij laten lopen. Leuk voor kunstliefhebbers(of andere mensen die dat leuk vinden) maar als je gewoon wil tanken en betalen rete irritant.
En dan kun je wel zeggen dat je met een pasje een tussendeur kunt openen. Maar had die deur dan gewoon open gelaten. Dan kunnen de kunstliefhebbers even door de galerij lopen terwijl de rest nergens last van heeft.

Samengevat: Er zijn mensen die niets anders willen dan zooi op hun mp3speler knallen. Dan kan het nog zo leuk/handig zijn wat je hebt bedacht daar hebben zij geen behoefte aan.
Koop dan een simpel MP3 spelertje van Craig of zo, kost $20 in de Wibra tegenover de $100 voor een iPod. Zelfde met foons, koop een Android of Motorola ipv een iPhone, die krijg je tegenwoordig zelfs 2 gratis naar je kop gegooid als je een enkel abo'tje aanschaft.

Maar dan krijg je ook wat je gekocht hebt voor die prijs en moet je niet klagen dat ze voorgeprogrammeerd zijn door de provider, de menutjes niet deftig in elkaar steken of dat het geluid naar de zak is.

Voor Jan-met-de-Pet en zelfs voor de gemiddelde Tweaker die iets op zijn telefoon/lawaaimaker wil zetten is simpele bestandsoverdracht via USB storage iewat spartaans. Ik heb liever een programmaatje dat dit doet voor mij zodra ik het apparaat insteek. En daar heb je iTunes niet voor nodig. Daarnaast heb je ook nog te maken met het feit dat de flash binnenin de iDevices tegenwoordig allemaal geencrypteerd zijn en dus kun je niet zomaar aan de private data komen.
Ik wil gewoon op vakantie een iPad meenemen en een fotocamera, geen laptop met iTunes. En wanneer ik in de bergen zit zonder internet in de buurt wil ik gewoon de foto's van mijn camera op mijn iPad zetten. Dus gewoon mijn CF kaartje in de iPad.

O jee dat kan helemaal niet. Toch maar een Windows Tablet nemen :)
@Wim-Bart
Als het een SD kaart is kan dat best.
Ik snap wel dat vele mensen iTunes handig vinden , en het handiger vinden dan mp3'tjes via een verkennen naar je toestel slepen.
Maar waarom de optie niet maken. Ik wil mijn mapjes, ik wil mijn files zien. ik wil zelf mijn muziek organiseren. Ok het kan wel , maar dan moet je jailbreaken en andere apps installeren.
Dat flash er niet is, is om dat het slecht in elkaar steekt en om dat veel content ook slecht in elkaar steekt. Beide zijn dat variabelen die een extern bedrijf niet in de hand kan houden. Er zijn natuurlijk ook scripters die het wel goed doen, en mensen die mooie dingen maken, maar buiten Windows is flash standaard een stuk stront dat je gewoon nooit goed kan toepassen. Binnen windows is het soms wel en soms niet bruikbaar, maar ook dat is gewoon niet consistent.

Verder is het Apple die inderdaad controle over zijn eigen winkel wil hebben, en het is Apple die zijn eigen producten maakt. Dat is helemaal niet gek. Je kan als je een BMW koopt ook niet naar Citroen gaan voor een firmware update. Je kan ook je Parker pennen niet vullen met niet-parker vulling. Je kan ook geen Coca-Cola flessen krijgen met Dr. Pepper er in.

Microsoft had het tegenovergestelde niet, en het was, en is, ook vrij illegaal wat er allemaal gebeurde en gebeurt. Dat je een update van de buurman 'kon gebruiken' en zomaar 'cabjes' op je toestel kon installeren was niet om dat microsoft lief was, maar om dat er nog geen bruikbare DRM was. Het is gewoon 100% illegaal om microsoft's OS of sotware te hacken (en dan bedoel ik de echte betekenis van hacken, wat dus niets met cracken te maken heeft wat gewoon bij de wet al illegaal is - hacken niet, dat is het aanpassen/bewerken e.d., en dat mag al niet volgens de EULA's van MS sinds 1995)

Dus dat verhaal is leuk, maar je komt er nergens mee aan. Het mocht niet, en het mag niet, en dat het eerder kon is geen uitzondering.
Als je het niet eens bent met een bedrijf of product ben je niet verplicht het nog steeds te gebruiken, flamer.
Huh? In deze context is het niet van toepassing, maar voor een monopolist bestaat per definitie geen alternatief.
Inderdaad, bij apple moet je eerst activeren voor je ipad iets doet.
Inderdaad, bij apple moet je eerst activeren voor je ipad iets doet.
En het verschil daarin met Windows is...?
Toch ben ik wel benieuwd hoe dit nou komt, in mijn herrinnering is het beduidend moeilijker om een kalender te schrijven die fout is dan een die goed werkt.
Dat zou je nog wel eens heel erg hard kunnen tegenvallen, hoe lastig het is om een 100% correcte kalender te implementeren die overal rekening mee houdt (alle schrikkeljaren met alle uitzonderingen, weeknummering, verschillende zomer/wintertijden in verschillende tijdzones, tijdzones met/zonder zomer/wintertijd, etc). Laat staan een kalenderfunctie die ook nog eens andere kalenders ondersteund behalve de westerse (gregoriaanse) kalender.

Niet dat dit geen domme bug is die niet voor zou moeten komen (al helemaal niet 2 keer in een jaar), maar ik denk dat je de complexiteit van kalender implementaties behoorlijk onderschat.
Nou, bij econometrie was dit onze allereerste programmeeropdracht. Er kwam toch nog aardig wat code bij kijken maar er waren ook mensen bij die nog nooit hadden geprogrammeerd, en toch lukte het iedereen wel. Dus m.i. toch een erg knullige fout van de programmeur van Apple.
De kalender is ook niet het probleem. maar de wekker functie in combinatie met de kalender :)

BTW. Heb jij je geprogrameerde kalender nog in gebruik? Volgens mij is er 1x in de zoveel jaar toch een verandering. Vorig jaar zijn de zomertijden aangepast als ik me niet verkeerd heriner. Zo zijn er nog tal van andere dingen.
Dan hebben jullie duidelijk niet goed genoeg getest. Ga eens bekijken hoe zomer/wintertijd geregeld worden. Dat is je reinste hel om te moeten programmeren. Nu valt het mee, maar vroeger was dat 'zoveel dagen na <specifeke christelijke dag>, tenzij dat op een zondag viel, dan een week later' en dat soort onzin.

En dan hebben we 't nog niet gehad over dat vroeger elke gemeente een ander idee van tijd had, dat, toen dat geregeld was, de offset tot GMT 19.32 seconden was, etc. Geloof me, dit is cht heel lastig.

[Reactie gewijzigd door CyBeR op 3 januari 2011 04:42]

Nee, en dat lijkt voor elk nieuwjaar te gelden als je hier kijkt.
Lezen is ook een vak:
And 1.1.2013 is fine
Dus niet voor elk nieuwjaar. De genoemde symptomen wijzen er eerder op dat het inderdaad om een weeknummer/jaar probleem lijkt te gaan analoog aan de hiervoor genoemde PHP date() problematiek:

2011: 1 en 2 januari doen het niet goed
2012: 1 januari doet het niet goed
2013: ook 1 januari doet het gewoon goed
En dat betekent dat men niet heeft nagedacht (en Q&A nogal te kort heeft geschoten) want het bestaan van week 53 is algemeen bekend en zou dus gewoon getest moeten worden. DIt zou 1 van de eerste dingen zijn die in een testplan voor een kalender moet komen. Test speciale situaties/ grenswaarden Hier is dat schijnbaar niet gebeurd (eerst wintertijd/zomertijd) nu 1 januari.

Ik hoop dat men de rest van het systeem beter test.
Als ik het goed begrijp komt het niet doordat er een week 53 is (want die was er niet in 2010) maar komt het doordat de eerste dagen van het nieuwe jaar qua weektelling nog in het oude jaar vallen.

Lijkt me een erg leuk probleem om te debuggen :)
Decennium Bug, hele wereld ligt nu op zijn kop! We zijn weer terug bij het jaar ... 2001 nu, toen er nog geen Iphone bestond, tablets nog een fail waren en niemand ooit van 3DTV of netbooks gehoord had.
2011 wordt het jaar van Android! Dus bedankt Apple voor deze fail ;)
In elke software zitten bugs: mijn wekker is bijvoorbeeld ook niet afgegaan vandaag (is een wekker die zich elke zondag herhaald), en m'n toestel draait momenteel op Android 2.1. Of dat nu aan het OS lag, dan wel aan de schil erover (Touchwiz) of aan nog iets gans anders, laat ik bij deze in het midden, maar het was dus niet enkel iOS waar de wekker wat rare toeren kreeg.

Overgins wel vrij irritant, maar ook niet het einde van de wereld. De bug verdwijnt vanzelf, en ik was vanmorgen nog net op tijd op mijn werk.
Ik hoop niet dat je een intiem SMS'je stuurt aan je vriendin en dat die dan per ongeluk bij een zakelijke connectie van je terecht komt...
De bug verdwijnt niet vanzelf, je hebt er alleen geen last meer van (voorlopig) ;)
Niemand heeft de bug ooit aan kunnen tonen, steeds meer mensen denken dat het gewoon user error is.
Niemand heeft de bug ooit aan kunnen tonen, steeds meer mensen denken dat het gewoon user error is.
Kunnen we dit dan textgate gaan noemen?
Gezien de marktgroei van Android is het opzich niet zo gek om te stellen dat 2011 het jaar van Android kan gaan worden. Niet dat Apple verdwijnt, maar de groei van Apple zou best weleens tot stilstand kunnen komen, terwijl Android nog een redelijk toekomstperspectief heeft.
De groei van iPhone bedoel je waarschijnlijk, waarmee ik het wel eens ben (als iPhone gebruiker, een zeldzaamheid :P ).

Maar Apple heeft nog andere producten waartegen Android nog niets kan tegen beginnen (iPads & iPods), of waar Android zelfs helemaal niets mee te maken heeft zoals hun hele laptop- en desktopgamma. Die laatste producten richten zich op een heel specifiek publiek, dat elders geen alternatief vindt. Dat Apple's groei tot stilstand zal komen door Android gebeurt dus volgens mij pas wanneer Pinksteren op Pasen valt. De iPhone zal wellicht wl serieus wat tegengas krijgen in 2011.
Er komt waarschijnlijk wel een grote groei in Android tablets! In 2011 zullen er namelijk versies van Android uitkomen die wel goed tablets ondersteunen 8-).

Wat gaan we trouwens weer heerlijk offtopic!

Deze faal doet me lichterlijk denken aan het decennium (ookal was ik toen een klein kind, mijn vader vind het leuk om dat soort dingen weer naar boven te halen).
en in 2012 lezen we dan allemaal negatieve berichten over Android en dat Apple eigenlijk toch zo slecht niet was.
Zo blijft men eeuwig door klagen over een foutje in een stukje software.
zo gaat het toch altijd?
Zie MS Xbox RROD
Zie MS Windows VISTA
Zie Apple iPhone
Zie alle andere populaire software en hardware producten.

wat Populair is zal altijd het doelwit zijn bugs. MS heeft jaren de VLAG mogen hanteren. Zie flame war bij BMW toen bekend werd dat zij een HUD wilde maken met de kernel van MS.

Voor het uitzetten van de motor moet eerst de startknop worden ingedrukt??? iemand??
Je wil de startknop als voorbeeld gebruiken? Besef je dat de functionaliteit van het contactslot (aan/uit zetten met zelfde UI element) in de autowereld veel eerder is geintroduceerd? Windows heeft dat idee van auto's gekopieerd, niet andersom.
Volgens ontwikkelaars zal iOS anders toch nog enkele jaren de fanfare aanvoeren. Maar ja Android gebruikers lopen met een gesloten bril rond dus die zullen toch blijven roepen hoe goed hun iPhone kopie wel niet is en dat de iPhone faalt als de wekker het niet doet maar daarbij verzwijgen ze natuurlijk dat je met Android niet deftig een sms kan versturen.


Android still has horrible text messaging bugs that'll get you fired, busted, or otherwise embarrassed


Of hoe Tweakers zijn lezers bedriegt door steeds op de fouten van de iPhone te wijzen maar doelbewust de gebreken van Android te verzwijgen.
Je kunt je in alle hoeken en bochten wringen, en kinderachtig proberen te wijzen naar andere merken (ja maar hunnie hebben ook bugs, boehoeoe), maar het blijft een onmiskenbaar feit dat de wekker van Apple hier keihard faalt, en die van andere merken niet. En dr gaat het over, in dit topic :)
oh maar ik reageerde op de reactie die stelde dat 2011 het jaar van Android zou worden. Onbegrijpelijk wat dat in dit topic komt doen natuurlijk ;)

Dat de wekker heeft gefaald en dat er koppen moeten rollen bij quality control had ik al gepost dus nee ik wring me niet in alle bochten ik reageerde enkel op dat die onzin reactie. :)
@WTF?: Ah ok, ik heb 'flat mode' aanstaan, dan krijg je dat :P

In dat geval is m'n post bedoeld voor die anderen die denken dat met wijzen het probleem minder erg wordt ;)
En die zelfde sms komt gemiddeld op en iphone een uur later aan.
You don't want to work on new year... There's an app for that!
It's not a bug, it's a feature!

Is een wekker zo'n moeilijk ding om te programmeren dan? Het is toch een kwestie van cijfertjes die doortellen?

Bij een grote verandering (jaar 2000) kan ik me de commotie nog voorstellen, maar nu?

[Reactie gewijzigd door TMPJ op 2 januari 2011 11:14]

Cijfertjes die doortellen? Je bedoeld dan toch niet rekening houden met alle tijdszones, alle winter en zomer uren. Schrikkeljaren en uren.

Een klok programeren is moeilijker dan je denkt.
ik hoop toch echt dat men dat 1x gemaakt heeft en telkens hergebruiken in al hun producten...
Wat een onzin. Een beetje programmeer of framework heeft daar prima functies voor.
Als je in een hogere taal werkt misschien. Maar als je je eigen operating system bouwt doe je dat allemaal zelf.
Reken maar dat er iemand bij Apple op straat is gezet per 1 januari. Of 3 januari. Misschien was de programmeur zelf wel te laat op komen dagen en kunnen ze dat mooi als excuus gebruiken om hem te ontslaan. Prutsert.
Reken maar dat er iemand bij Apple op straat is gezet per 1 januari. Of 3 januari. Misschien was de programmeur zelf wel te laat op komen dagen en kunnen ze dat mooi als excuus gebruiken om hem te ontslaan. Prutsert.
Aannames, aannames en nog eens aannames. Waarom moet er nou meteen weer blooooeed, blooeeeed geroepen worden als we nog niet eens weten hoe de vork in de steel zit ?

Het kan net zo goed een hele bekwame programmeur zijn die nu een keer faalt. Of misschien is het wel een complexe situatie waarbij aanpassingen in schijbaar ongerelateerde API's, applicaties, etc. dit veroorzaakt hebben.

Het is allemaal wel door QA heen gekomen. Wie ze keuze was het om geen / te weinig / welke unit tests te maken voor die applicatie ? Wat waren de omstandigheden voor dit project zoals tijdsdruk etc. ?

Het is nog niet te laat om nuance toe te voegen aan het rijtje van goede voornemens....
Gewoon foutje, kan gebeuren. Word echt niemand om ontslagen hoor.
Als jij een wekker zou programmeren dan zou je ook niet meteen aan zo'n functie denken.
Zie de reactie van CIStem. Daarbij is iOS niet helemaal zelf geschreven, er wordt juist gebruik gemaakt van een hoop bestaande libararies (WebKit) etc.
iOS maakt gebruik van WebKit 8)7
Daarbij is iOS niet helemaal zelf geschreven, er wordt juist gebruik gemaakt van een hoop bestaande libararies (WebKit) etc.
iOS maakt net als OSX gebruik van de XNU kernel.
Alleen de BSD POSIX laag, OpenGL,OpenAL en WebKit zijn niet of gedeeltelijk door Apple geschreven.
De rest, IOKit, GCD, CoreGraphics, QuartzCore, CFNetwork, UIKit etc komen van Apple's hand.

[Reactie gewijzigd door Carbon op 2 januari 2011 16:58]

En programmeertalen en frameworks worden door hogere machten aan de mensheid gegeven? Nee dus, die worden ook gewoon door mensen gemaakt, dus daar kunnen fouten in zitten. Zo'n framework moet namelijk precies doen wat tc982 zegt: met heel veel zaken rekening houden.

Neemt niet weg dat Apple er op iOS een potje van heeft gemaakt met die alarmfunctie. Eerst al die bug bij de overgang naar de zomertijd en nu deze.
OS X gebruikt in ieder geval International Components for Unicode voor internationalisatie en localisatie van datum en tijd (onder andere). Nu is dat natuurlijk geen garantie dat iOS dat ook gebruikt, maar aangezien Apple zelf ook naar ICU commit (en actief betrokken is), kan ik me heel goed voorstellen dat ze dezelfde libraries gebruiken (al dan niet gewrapped door Objective-C code).

Sterker nog, het staat zelfs vermeld dat "iPhone OS" het gebruikt.

Uit ervaring weet ik dat ICU extreem flexibel is, maar ook redelijk complex om te gebruiken. Deze bug klinkt alsof het uit "week 53" komt. Vooral omdat hij op 3 januari weer gefixed is. Dat klinkt dan niet als een bug in ICU, maar een verkeerd gebruik van de Calendar fields (begrijpelijk, hij heeft nogal wat velden en datum en tijd calculaties kunnen behoorlijk complex worden als je rekening moet houden met allerlei locales).

[Reactie gewijzigd door CIStem op 2 januari 2011 13:59]

Ja... maar zo'n framework moet ook eerst gemaakt worden. En dat framework zit in dit geval in iOS.. waar de bug in zit.
Radiografische klok en klok via de GPS. Het wiel moet je niet twee keer uitvinden.
Het gaat helemaal niet om de klok, die loopt prima op tijd.

Het gaat om de triggers voor het alarm. Daarbij moet je rekening houden met veranderingen, ook nadat je het alarm gezet hebt (de gebruiker kan z'n tijdzone wijzigen, of de tijdzone kan automatisch gewijzigd worden i.v.m. zomer- of wintertijd, etc.). Je wilt dan nog steeds dat het alarm om 8.00 lokale tijd afgaat. Dat betekent dat je de trigger moet herberekenen.
Wat is dat voor onzin.. Lijkt me logisch dat alleen de systeemtijd veranderd zodra je een andere tijdzone betreedt. Dus triggers herberekenen lijkt me compleet overbodig aangezien die toch hetzelfde blijven...
Als jij hier een wekker zet voor 8 uur, en je vliegt daarna naar New York, hoe laat moet de wekker dan afgaan? Het is niet zo dat die bug hierdoor komt, maar het geeft maar aan dat het complexer is dan het op het eerste gezicht lijkt, wat ook al door meerdere anderen is aangegeven.
Sim-pel. Gewoon om 8 uur, want je wilt blijkbaar om 8 uur wakker worden. Tijdzones doen niet ter zake. Als ik in New York ben of waar dan ook, wil ik op lokale tijd gewekt worden niet op Nederlandse tijd. Die paar betweters die het per s anders willen doen, moeten dat maar zelf uitrekenen.
Slechte programmeur! Als jij dan een mailtje stuurt met een afspraak naar iemand in China moet die ook om 8 uur op de afspraak zijn? Je gaat enorm slecht om met internationalisatie.

Als je een afspraak maakt om 8u moet dit opgeslaan worden in een systeem-onafhankelijke tijd - meestal GMT (met een Unixtime int64 of zo). Dan kun je dit terugrekenen naar de tijdzone van de lokale client al dan niet met de lokale versie van zomer/wintertijd.

Als je echter een herhalend event hebt moet je dit opnieuw opslaan in een systeem-onafhankelijke tijd maar je moet ook erbij zetten dat elke keer de zomer/wintertijd omslaat je er een uur bij of terug moet rekenen afhankelijk van de status van de zomer/wintertijd gedurende het eerste of originele event.

Het wordt een stuk lastiger als je een herhalend event hebt die zich niet elke dag moet herhalen maar vb. elke zondag, dan moet je rekenen met de weken van het jaar. Je kunt niet zomaar seconden of dagen gebruiken want dat varieert (afhankelijk van de zon, het jaar etc. etc.)

Datums zoals wij ze kennen zijn enorm complex om te implementeren in een wiskundig systeem. Dit komt omdat de datums die wij gebruiken op een minder precies (kosmisch gezien) en enorm arbitraire berekening zijn gebaseerd (dat er 365 dagen zijn of 52 weken of 24 uren in een dag is allemaal verkeerd).
Datums zoals wij ze kennen zijn enorm complex om te implementeren in een wiskundig systeem. Dit komt omdat de datums die wij gebruiken op een minder precies (kosmisch gezien) en enorm arbitraire berekening zijn gebaseerd (dat er 365 dagen zijn of 52 weken of 24 uren in een dag is allemaal verkeerd).
En tch hebben Microsoft, Google, HTC, Samsung, RIM, Nokia, etc. daar allemaal geen probleem mee, maar Apple wl :P
Eh, da's weer de verkeerde aanname, alleen nu de andere kant op.

Je kunt bij een event om 8 uur 's ochtends (tijdzone niet gespecificeerd) niet zomaar aannemen dat die tijdzone-absoluut of tijdzone-relatief is. Een afspraak om iemand te bellen is absoluut; een wekker is relatief.

Ja, dat is lastig. Mensen willen bij voorkeur niet over dat soort dingen nadenken. Maar computers zijn niet helderziend, dus die moeten iets. De beste oplossing tot nu toe is om "events" goed te klassificeren. Een "wake up call" is duidelijk tijdzone afhankelijk, een meeting is dat niet.

Bij het opslaan daarvan moet je het meteen goed opslaan. Dat wil dus zeggen dat je absolute events absoluut opslaat (in UTC), en relatieve relatief (t.o.v. de relevante kalender, bijvoorbeeld ma-vr 08:00). Als je het anders doet, dan blijf je omrekenen. Je wil niet weten wat voor gedonder je krijgt als je rond het begin van zomertijd heen en terug naar de VS vliegt, waar andere zomertijdregels gelden.
Het gaat helemaal niet om de klok, die loopt prima op tijd
Ahem, dan heb je nog nooit goed naar de klok van je iphone gekeken, want die loopt namelijk helemaal niet keurig op tijd.

Tenzij je 'm jailbreaked is het niet mogelijk het ding goed op tijd te laten lopen.
30s tot 2 minuten verschil is heel normaal. Handmatig het ding goed zetten is ook onmogelijk. (hoe goed je het ook probeert, dat ding gaat toch weer 30s verkeerd staan)

Voor mensen de klok op de iphone gebruiken om hun trein te halen is dat ontzettend irritant.
Bij moderne OS'en worden datum en tijdsfuncties (zoals Tijdzones, winter/zomer, schrikkeljaren) door het OS of het framwork afgehandeld.

Een wekker functie is dan ook hl simpel en kan je in 3 regeltjes schrijven.
een simpele loop die altijd nakijkt hoe laat het is en begint te spelen als een bepaald uur is aangebroken.
En een loop die dus continue processor tijd vraagt en dus batterij verbruikt. Lijkt me niet netjes om een loop te schrijven die dat doet, tenminste als je geen sleep gebruikt om deze ook weer te laten wachten.
@hierboven
IStealYourGun bedoelt waarschijnlijk duidelijk te maken hoe simpel een wekker in elkaar kan zitten, dat dit vaak niet zo is omdat het niet praktisch/elegant/zuinig is, is een ander verhaal
verder is dit een faal verhaal (dat rijmt ;) )
Dan zou het kunnen dat die wekker 1 keer per week kijkt of er voor die week alarmen zijn, en alles wat niet die week hoeft af te gaan 'vooruitschuift' om er pas over een week weer naar te kijken.

3 januari begint week 1, dus begin 3 januari 0:00 kijkt die wekker welke alarmen die week moeten afgaan.

Maar mogelijk ziet het apparaat 1/2 jan niet als wk52 uit 2011, en wk 0 2011 begint niet op een maandag o.i.d.

Het idee om te optimaliseren voor zuinigheid is dan goed, maar de uitvoering zuigt dan nogal.
Waarschijnlijk is de alarmfunctie in iOS geschreven door iemand net als jij. Dit soort oversimplistisch denken, is precies waar het fout gaat.

Wat als de gebruiker z'n tijdzone wijzigt na het instellen van het alarm? Wat als de zomer- of wintertijd ingaat? Dan zul je wel dat "bepaalde uur" moeten aanpassen. Kan jouw simpele loop dat?

Het probleem zit in alle gevallen in de vertaling tussen een bepaald moment in de tijd en de vertaling naar de lokale tijd van de gebruiker.

Stel, het is nu 14:00 CET op zondag 2 januari 2011. Ik stel een alarm in voor 8:00 morgenochtend. Nu vlieg ik straks naar London. Daar is het 1 uur vroeger. Op het moment dat ik het alarm instelde, was het daar 13:00 GMT. Wanneer moet het alarm afgaan?

Niet dat dit een excuus is voor de bugs in de iOS Clock.app, maar zo simpel als "3 regeltjes" is het zeer zeker niet.

[Reactie gewijzigd door Herko_ter_Horst op 2 januari 2011 13:46]

@echo off
set alarm=15:01
:top
if %time:~0,5% NEQ %alarm% timeout 1 /NOBREAK > nul & goto top
echo alarm
pause

Bovenstaande is hoe je het zou doen met een bat script onder windows.
Stel dat je tijdens het lopen van dit script de tijd zou aanpassen van windows, dan heeft dat geen enkel invloed op de werking en zal het nog steeds afgaan om 13:43 "systeem" tijd. En als je dit in een programma zou steken dan is dit de logica die ik zou gebruiken voor de class alarm. Het enigste verschil is dat %alarm% in het programma een collectie zal zijn van %alarmen%, de echo zal een event zijn en er zullen nog enkele functies inzitten om het object te besturen.

Zeer simplistisch, maar dat is het ook, alles wat betreft het veranderen van het uur is niet de verantwoordelijkheid van het object alarm, maar van het object (system)time, van het OS. Ongeacht in welke taal je programmeert.

Stel dat ik bovenstaande app zou draaien op mijn laptop en zet hem om 6u. Ik ga naar Engeland en zet mijn laptop op de locale tijd, dan zal die app afgaan om 6u Engelse tijd.

[Reactie gewijzigd door IStealYourGun op 2 januari 2011 15:01]

Alsjeblieft zegt, komt ie aan met een batch script om aan te tonen hoe eenvoudig het allemaal wel niet is. Ergens ben je ongeveer 4 niveaus van abstractie kwijtgeraakt om de clock bug in iOS te willen relativeren geloof ik.

Neem nou maar aan wat Herko_ter_Horst zegt, dat je niet over voldoende kennis beschikt om te kunnen beoordelen op hoeveel duizenden verschillende manieren je een fout kunt maken bij het implementeren van een kalender of een wekker functie, precies zoal hij al zegt; het soort oversimplificeren van dit soort dingen is precies wat tot dergelijke fouten kan leiden.
John, ik denk dat jij het moeilijker wilt laten lijken dan het is. Een basis OS call die helemaal niet abstract moet zijn. Ooit in ver verleden programmeerden we dit soort zaken op 68000 unicorn unix systemen in C en assembler en zo complex was dat niet als jij doet schetsen. In principe is het inderdaad niks meer dan een OS Call waarin een Event wordt gezet. En het OS heeft een loop in de kernel die dit soort zaken afhandeld. Blijkbaar zit er gewoon een bug in de kernel want uitgaande van UTC en unixtime is afhandelen van timezones geen enkel probleem net zoals het afhandelen van zomer/wintertijd.
Stel, het is nu 14:00 CET op zondag 2 januari 2011. Ik stel een alarm in voor 8:00 morgenochtend. Nu vlieg ik straks naar London. Daar is het 1 uur vroeger. Op het moment dat ik het alarm instelde, was het daar 13:00 GMT. Wanneer moet het alarm afgaan?
Wat mij betreft mag de tijd die je hebt ingesteld hetzelfde blijven, dus 8:00 GMT moet hij afgaan. Dat zal niet altijd de bedoelde tijd zijn, maar als programmeur kun je niet weten wat de gebruiker in die kwestie wil. Het netste is dus gewoon even een prompt om te vragen of die gebruiker zijn wekkers wil corrigeren en dan daarop te reageren.
De grap is dat de klok het wel doet, dus dan lijkt het me toch niet vreselijk moeilijk om 1x per minuut te pollen hoe laat het is, of om een event te schedulen op een tijd.
dus dan lijkt het me toch niet vreselijk moeilijk om 1x per minuut te pollen hoe laat het is
Met n keer minuut pollen heb je al kans dat een alarm gemist wordt want het is onmogelijk exact om de 60 seconden te pollen, je krijgt dus onherroepelijk te maken met drift en dat kan in sommige randgevallen een probleem worden.

Voorbeeld: alarm = 13:00

Stel de eerste poll is op 12:59.999 (.999 = 999ms) (geen alarm)

en de tweede poll op 13:01.000 (ook geen alarm want de tijd is <> 13:00)

Een ander gevolg van drift kan zijn dat het alarm te laat afgaat.

Worst-case scenario:

Eerste poll is op 12:59.000 (geen alarm)

en de tweede poll op 13:00.999 (alarm gaat bijna een minuut te laat af)

De quick en dirty oplossing is sneller pollen maar dat kost meer energie en dat gaat dus ten koste van de accu.
Beter is het om het pollen te synchroniseren met de tijd.

while(true) {
sleep((60-time.seconds)*1000);
if (time == alarmTime) {
soundAlarm();
}
}

[Reactie gewijzigd door Carbon op 2 januari 2011 17:45]

Eh, daarom doe je bij polling ook altijd/het liefste ">= " of "<=" en nooit "==" als je niet exact weet wat je kunt verwachten :).

Wel heb je gelijk dat het alarm dan maximaal net niet een minuut te laat. Polling is ook niet de ideale oplossing natuurlijk, iets als aan OnMinuteChangedEvent gaan hangen is (zoals ik ook als 2e optie noemde)
Eh, daarom doe je bij polling ook altijd/het liefste ">= " of "<=" en nooit "==" als je niet exact weet wat je kunt verwachten .
Ik zat er al op te wachten :)

== vervangen door >= gaat niet werken!

Dat heeft namelijk als gevolg dat een nieuw alarm vroeger dan de huidige tijd meteen afgaat.

Waar het om gaat is dat je controleert of de klok de alarmtijd bereikt (==) of passeert!

lastPollTime = time;

while(true) {
sleep((60-time.seconds)*1000);
if(lastPollTime <= alarmTime && time >= alarmTime) {
soundAlarm();
}
lastPollTime = time;
}
iets als aan OnMinuteChangedEvent gaan hangen is (zoals ik ook als 2e optie noemde)
OnMinuteChangedEvent is OS afhankelijk, de sleep aanroep in mijn voorbeeldcode doet hetzelfde maar dan OS onafhankelijk.

[Reactie gewijzigd door Carbon op 3 januari 2011 09:43]

Ah, bugs zijn zo makkelijk te maken. Dit ding kan twee keer afgaan, als time==alarmTime. De volgende keer is lastPollTime == time && time > alarmTime;

Je bedoelt dus if(lastPollTime < alarmTime && time >= alarmTime)
Lol, pollen. Daarnaast gebruik je de reeds ingebouwde time functies. Als je een apparaat ontwikkelt (zoals een computer of een ipod) moet je van de grond af die functies opbouwen en begin je bij: dit is een 10MHz kristal, verbind dit aan pootje 16 van de processor en elke keer je een interrupt krijgt van dit pootje, voeg 100ns toe aan de lokale klokvariabele en dat is enkel hardware/firmware. Dan kun je beginnen dit in de kernel te implementeren en de unixtime berekenen. Dit moet je dan kunnen doorgeven aan een framework die de zomer/wintertijd bijhoudt voor elke tijdszone. En dan nog heb je enkel GMT en je lokale tijd, niet hoeveel seconden het gaat duren alvorens je Januari 1 2011 tegenkomt, welke tijdszone het apparaat op dat moment is alswel de veranderingen die zijn doorgevoerd aan het zomer/wintertijd systeem.
Wat jij beschrijft is hoe je een software klok/kalender implementeert .
BTW om de 100ns een interrupt genereren kost teveel overhead, dat is ook de reden dat er altijd een hardware counter/timer wordt gebruikt die zo is ingesteld dat er b.v. om de 1ms een interrupt wordt gegeneerd. Resultaat, een lage overhead en toch een resolutie van 100ns.

Of je alarm timers implementeert op low of high level maakt niet uit, je ontkomt niet aan het periodiek pollen van de datum/tijd want ergens moet er gecontroleerd worden of de klok de alarmtijd passeert.

[Reactie gewijzigd door Carbon op 3 januari 2011 09:22]

Wij deden dat vroeger gewoon door een Eventqueue te bekijken. Dit werdt 18.2 maal per seconde gedaan (op hw interrupt).
Programmeren is altijd makkelijk en als er bugs op treden altijd lastig. Testen daar gaat het om in dit leven. Het bewijzen dat de functionaliteit werkt. Als die prutsers bij Apple nu goede testers hadden die gewoon een standaard transitie test hadden opgenomen in hun test specificaties was dit niet gebeurt.
Wat ook erg makkelijk is, is vanaf de zijlijn roepen hoe het allemaal maar getest moet worden, vooral door achteraf te stellen dat ze deze case ook maar even in 'een transitietest in hun test specificaties op te nemen'. Iedereen die software ontwikkeling van dichterbij kent dan uit een of ander boekje weet dat 100% test coverage onmogelijk is, en je altijd een keuze maakt om zoveel mogelijk general cases en corner cases af te dekken, maar dat je ook ergens een lijn moet trekken, je kunt niet oneindig veel test cases blijven schrijven. Deze kalender bug lijkt me een combinatie van een heel aantal factoren die je makkelijk over het hoofd kunt zien bij het schrijven van je test cases. Daar hoef je echt geen prutser voor te zijn.
Blijkbaar is het moeilijk (bij Apple).
Twee datum/tijds gerelateerde bugs is wel veel in een korte tijd.

Ik mag verder aannemen dat deze bugs goed te reproduceren zijn en dus al eerder herkend hadden kunnen worden.
Bugs in software komen altijd voor alleen de kans op een bug is vaak niet groot bij goed geschreven software en doet zich dan alleen voor in een heel specifieke situatie.
Daar is hier geen sprake van, want een wekker op een bepaalde datum instellen is niet zo bijzonder.
Het zou wat anders zijn als je je wekker zou willen instellen in 2211 en het dan niet zou werken.
Goh, op elk tijdstip kan je wel bepaalde speciale problemen vinden, lijkt me. Natuurlijk zijn die bugs reproduceerbaar; maar dat maakt ze nog niet eerder herkenbaar. Om een bug te voorzien met test cases moet je de valkuil al hebben zien zitten (en dan zou die bug er in principe niet meer in moeten zitten).

Ik ben zelf geen Apple-fan; maar er zijn genoeg tijdsgerelateerde bugs te vinden: ook de PS3 heeft al last gehad van dergelijke problemen (ook rond een iets specialer moment, namelijk rond 29 februari, net zoals nu het geval is rond nieuwjaar).
Er zijn een aantal speciale tijdsovergangen die je als ontwikkelaar ZEKER moet testen. O.a. schrikkeljaren, jaarovergangen en zomer/wintertijd omschakelingen.
Ik zeg dus niet dat ze ieder jaar moeten testen, maar de overgangen wel.
Maar als een bug wederkerend is zoals in dit geval dan word het al wat erger. Na het eerste voorval had men een degelijke audit moeten doen van de code, iets wat blijkbaar niet gebeurd is.
Programma's die gebruik maken van de datum en tijd zijn 1 van de moeilijkste om te maken.
zouden wel het best getest moeten worden, veel zaken hangen af van een kalender/tijd, daar leeft men mee.
Of het gebruik van een hardwareklok of RTC kan dit probleem ook wel voorkomen lijkt me?
Of het gebruik van een hardwareklok of RTC kan dit probleem ook wel voorkomen lijkt me?
Nee! De klok is niet het probleem (tijd en datum zijn correct).
Hmm dat verklaart. Ben net wakker.
goh dan betaal je veel geld voor die iphone, zou je toch zeker kunnen verwachten dat alles 100% is of niet?
Voor een Android betaal je ook veel geld, en Android is ook zeker niet bugloos ;)
Je betaald minder voor een Android, en je krijgt minder bugs.
Misschien zijn het die ingebouwde bugs wel die dat iDing zo duur maken.
Sorry ze, maar een simpele wekfunctie die begint te flippen bij winter/zomeruur n dan ook nog eens bij het omschakelen van het jaar...
:X
http://code.google.com/p/android/issues/list :z

SMS are intermittently sent to wrong and seemingly random contact.
Om maar een interessante te noemen.

@theemstra Ik zeg ook zeker niet dat er geen waslijst is aan bugs voor iOS. Ongetwijfeld. Ik geef alleen aan dat de conclusie dat Android minder bugs bevat dan iOS geen steek houdt. :)

[Reactie gewijzigd door BastiaanN op 2 januari 2011 11:34]

Ehh,

Dacht je dat er niet zo'n waslijst aan bugs is voor iOS?
Dat is het punt toch niet? Er wordt beweerd dat er nauwelijks bugs voor android te vinden zijn en dan geeft BastiaanN een reactie door aan te geven dat dat totaal niet het geval is. Niemand beweert dat er niet zulke bugs zijn voor iOS... Sterker nog dit artikel gaat over n van die bugs.
Android heeft ook nog een openstaande bug die een tikje erger is

http://code.google.com/p/android/issues/detail?id=9392

-edit- Bastiaan was me voor :)

[Reactie gewijzigd door plakbandrol op 2 januari 2011 11:31]

Ehm, als je het verhaal achter je link doorleest kun je zien dat de bug niet in Android maar in HTC Sense zit.
het is een beetje te makkelijk om 1 bugje af te schuiven, de android issue-list zijn 9049 bladzijden met elk 50+ gerapporteerd bugs, dus een kleine 452.000 gedocumenteerde issues.
9049 issues ja, niet pagina's (als je op volgende / vorige klikt zie je het duidelijker), daarbij komt dat er ook Enhancements tussen staan, en het aantal bugs te vinden in die bugtracker "maar" 6650 is, waarbij een heel groot deel maar door < 10 mensen is ondervonden, de laatste 500 ~ 1000 zijn niet eens heel actieve threads (met 1 post van iemand die het ook vind). De laatste 0 ~ 500 bugs zijn pas echt veel besproken.

[Reactie gewijzigd door XiniX88 op 2 januari 2011 12:40]

Als ik die link hierboven bekijk zijn het maar 9049 gerapporteerde issues. (http://code.google.com/p/android/issues/list)

[Reactie gewijzigd door Twazerty op 2 januari 2011 12:50]

Android blaast wel niet zo hoog van den toren dat ze het beste zijn, dat ze de heilige graal zijn, "dat andere toestellen dat ook hebben", "dat zijn gebruikers het toestel verkeerd vast houden", ze ontkennen ook de problemen niet, ...
Er zitten ook mensen tussen die hinder ondervinden met een Nexus One of een Samsung Captivate. Die draaien beiden geen Sense. Desalniettemin zijn er nog genoeg bugs over die wel voor elk toestel gelden.
Nope, dit is niet Sense gerelateerd. Heb het ook op mijn Samsung Galaxy S veelvuldig gehad. Een van de vele redenen om dat ding uit het raam te gooien en over te gaan op een ander toestel. Dit is namelijk erg vervelend als je een smsje naar een vriendin stuurt en dit bericht bij een klant van je terecht komt ... iets dat me dus gebeurd is. Gelukkig nam hij het goed op en kreeg ik een humoristisch bericht terug. Dit maakt voor mij zo'n device al direct onbruikbaar voor zakelijke toepassing en tot dat dit soort rampzalige dingen verholpen zijn kom ik niet terug op Android.

Dan is een wekker die op 1 januari niet afgaat in mijn optiek nog niet zo'n ramp :)
Toch bedankt dat je de issue gemeld hebt zodat het gefixed kan worden.
Je hebt gelijk, want issue is door 1 persoon gemeld, half jaar geleden. En daarna heeeft niemand er last van gehad tot het opeens twee dagen geleden massaal gemeld werd. Klopt gewoon iets niet.
Je betaald minder voor een Android,
Hangt af van het toestel, er zijn Andoid toestellen die kwa prijs aardig in de buurt van een iPhone komen.
en je krijgt minder bugs.
Dat betwijfel ik.
In de buurt misschien wel, maar dan heb je het over een toestel dat betere specs heeft dan de iphone en nog steeds goedkoper is. Je kan een Android-toestel kopen voor 200 euro (waar de wekker wl werkt)
maar dan heb je het over een toestel dat betere specs heeft dan de iphone en nog steeds goedkoper is.
High-end smartphones zijn kwa hardware bijna identiek. Uitzondering misschien de Nexus-S want die heeft als extra NFC aan boord.
Je kan een Android-toestel kopen voor 200 euro (waar de wekker wl werkt)
Alsof de wekker de enige reden is om een smartphone aan te schaffen, tssss.
Vind ik wel meevallen hoor. Je hebt verschillende chipsets, ARM, Qualcomm, en deze hebben beide ook weer meerdere verschillende chipsets. Daarbij hebben ze verschillende schermen (qua grootte, pixeldichtheid, type), camera's, batterijen, en zo kan ik nog een tijdje doorgaan.

Nu over bugs; Ik denk dat elk individueel android toestel minder problemen heeft dan de iPhone. Deze bugs en problemen zijn vaak ook nog eens zelf op te lossen, aangezien er een hele community (xda) makkelijke handleidingen maakt om veel voorkomende problemen te fixen.
Nu over bugs; Ik denk dat elk individueel android toestel minder problemen heeft dan de iPhone.
Pure speculatie, Apple's bugreporter (radar) toont alleen de zelf gerapporteerde bugs, maw alleen Apple weet hoeveel bugs er openstaan.

De Android bugreporter is wel publiek toegankelijk:

http://code.google.com/p/...20Owner%20Summary%20Stars

Bijna 6000 openstaande bugs!

[Reactie gewijzigd door Carbon op 2 januari 2011 17:35]

Voor een Android betaal je ook veel geld, en Android is ook zeker niet bugloos ;)
Ik betaal voor Android niets.
"Een Android" duidt op de telefoon zelf, maar dat had je natuurlijk wel zelf kunnen bedenken.
Ik betaal voor iOS ook niets.
De kosten van Android, Windows Phone en iOS zitten gewoon verwerkt in het toestel. Of kan je tegenwoordig ook een telefoon kopen zonder OS er op zodat je later een OS naar keuze er op kan installeren?

Het zou best kunnen dat dat kan, maar dan kan ik het nergens vinden. Daaruit concludeer ik een beetje dat het OS gewoon in de prijs van het toestel is meegenomen.

Vergelijkbaar met die abonnement constructies. Je kunt of je telefoon los kopen en dan betaal je daar zeg 400 euro voor. Of je kan je telefoon "gratis" krijgen bij een abonnement.
Alleen is die gratis telefoon helemaal niet gratis, want als je dat abonnement vergelijkt met hetzelfde abonnement, maar dan in Sim-only vorm zul je zien dat het abonnement met de "gratis" telefoon over de looptijd van het contract zo'n 500 euro duurder is dan het Sim-only abonnement.
Ik betaal voor Android niets
Dat is maar de vraag.
De meeste Android telefoon fabirkanten betalen licenties voor technologieen in Android aan bijvoorbeeld Microsoft en Nokia.
En daar kunnen straks nog licenties aan Oracle, Apple en Paul Allen bijkomen.
Voor een Android betaal je ook veel geld, en Android is ook zeker niet bugloos ;)
Dus omdat Android bugs heeft mag iOS het ook hebben? Wat een kromme redenering. Het gaat hier helemaal nietover Android.
Foutloze software bestaat niet, ook al doe je nog zo je best er is ltijd iets wat over het hoofd wordt gezien. Android heeft ook de nodige bugs, Symbian ook en elk ander stuk software wat je kunt verzinnen ook wel. Het gaat er meer om dat het erkent wordt en spoedig wordt opgelost :)
goh dan betaal je veel geld voor die iphone, zou je toch zeker kunnen verwachten dat alles 100% is of niet?
Voor minder geld koop je een wekker.
Als je software koopt weer je zeker dat dat niet 100% goed is, want bug vrije software bestaat niet.... volmaakte mensen overigens ook niet.. 't zal wel iets met elkaar te maken hebben. ;)
Maybe there's an app for that. :)
Vanmorgen pas om 7 uur op idd, en opvolgende collega kwam pas nadat ik dr wakkerbelde :D
Mogelijk mee te maken dat 1&2 Jan nog in de week van 2010 zit?
En 3 Jan mogelijk in de volgende week zit?

En hoe kunnen ze nu al aangeven dat het 3-jan is opgelost terwijl het nog niet eens deze datum is?
Door de datum een dagje vooruit te zetten...?
gewoon de klok vooruit zetten natuurlijk...
Je kan toch de datum even vooruit zetten en dan controleren of het wel of niet werkt?
Gewoon even de datum veranderen in de instellingen. Wel even automatisch synchroniseren (als dat er is?) uitzetten :)
Hier had ik al een tijdje last van? Ik weet even niet meer vanaf wanneer, maar ik moet al een paar weken handmatig me alarm aan zetten (uit zetten in het weekend)...

Ik weet het weer!

Deze bug heb ik vanaf de wintertijd! ...

[Reactie gewijzigd door Mister_X op 2 januari 2011 13:36]

De wintertijd bug heeft zichzelf bij mij na een aantal weken vanzelf opgelost. De wekker ging altijd een uur te laat (7 uur ipv 6 uur), toen heb ik een tweede wekker gezet (op 5 uur) op een uur eerder. Hierna ging mijn wekker om 6 uur en om 7 uur (2e keer dus in de auto). Na een aantal weken ging mijn wekker om 5 uur en om 6 uur af, dit heb ik maar een week zo gehouden voor de zekerheid, en sindsdien gewoon iedere dag om 6 uur weer.

Nu is er dus weer een probleem met de wekker, nu hoef ik volgende week pas weer te werken, maar ik zet toch maar een tweede wekker voor de maandag.
Yep ik had het gisteren en vandaag, moest vandaag me ouders wegbrengen naar schiphol en was bijna te laat. Gelukkig heb ik een kat die me heeft gewerkt.
Nou hij ging hier niet af vanochtend, maar mijn conventionele wekker gelukkig wel. Sommige mensen moeten vandaag werken :/
1 2 3 ... 10

Op dit item kan niet meer gereageerd worden.



Populair: Vliegtuig Tablets Luchtvaart Samsung Crash Smartphones Microsoft Apple Games Rusland

© 1998 - 2014 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013