Wekker iPhone faalt in nieuwe jaar

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.

De 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 (328)

[MrBucket]

Een quote van http://discussions.apple....threadID=2704137&tstart=0:
"A quick test, setting the date to 1.1.2012 and trying the alarm: nada. On 1.2.2012, alarm works, unlike 1.2.2011. And 1.1.2013 is fine.".
Dit zou verklaard kunnen worden als er op een of andere manier weeknummers worden gebruikt bij het opslaan van alarmmomenten - met de conventie dat weken beginnen op maandag.

Een mogelijke fout is dat ze dan het weeknummer van de week pakken in combinatie met het jaartal van de datum. Met andere woorden: een alarm op maandag 3 Jan 2011 wordt Maandag, week 1, 2011, maar een alarm op zondag 2 Jan 2011 wordt Zondag, week 52, 2011. Maar goed, wat er dan precies verkeerd is gegaan is vanaf hier natuurlijk niet te zeggen.

Het patroon zou wel kloppen: Want 1 en 2 Jan 2011 vallen op zaterdag/zondag van week 52 in 2010, 3 jan in week 1 van 2011.
1 Jan 2012 is een zondag, dus telt als de laatste week van 2011 (en gaat daarom fout), 2 Jan 2012 valt wel in week 1 van 2012 en werkt daarom wel.
1 Jan 2013 is een dinsdag, en werkt dus ook omdat het niet in de laatste week van het vorige jaar valt.

't Zou kunnen

[Reactie gewijzigd door MrBucket op 23 juli 2024 08:35]

[TMPJ]

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 23 juli 2024 08:35]

[tc982]

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.

[PolarBear]

Wat een onzin. Een beetje programmeer of framework heeft daar prima functies voor.

[gibraltar]

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 gibraltar op 23 juli 2024 08:35]

[frickY]

Als je in een hogere taal werkt misschien. Maar als je je eigen operating system bouwt doe je dat allemaal zelf.

[PolarBear]

Zie de reactie van gibraltar. Daarbij is iOS niet helemaal zelf geschreven, er wordt juist gebruik gemaakt van een hoop bestaande libararies (WebKit) etc.

[Carbon]

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 23 juli 2024 08:35]

[Anoniem: 364393]

iOS maakt gebruik van WebKit

[Royeboi]

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.

[34749]

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....

[Wolfos]

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.

[Herko_ter_Horst]

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.

[90710]

Ja... maar zo'n framework moet ook eerst gemaakt worden. En dat framework zit in dit geval in iOS.. waar de bug in zit.

[roy-t]

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.

[Carbon]

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 23 juli 2024 08:35]

[Guru Evi]

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.

[Carbon]

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 23 juli 2024 08:35]

[Wim-Bart]

Wij deden dat vroeger gewoon door een Eventqueue te bekijken. Dit werdt 18.2 maal per seconde gedaan (op hw interrupt).

[roy-t]

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)

[Carbon]

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 23 juli 2024 08:35]

[MSalters]

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)

[Iblies]

Radiografische klok en klok via de GPS. Het wiel moet je niet twee keer uitvinden.

[Herko_ter_Horst]

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.

[Lukosje]

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...

[Arthur]

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.

[Anoniem: 384399]

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.

[Guru Evi]

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).

[MSalters]

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.

[Anoniem: 384399]

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 tóch hebben Microsoft, Google, HTC, Samsung, RIM, Nokia, etc. daar allemaal geen probleem mee, maar Apple wél

[mjtdevries]

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.

[catfish]

ik hoop toch echt dat men dat 1x gemaakt heeft en telkens hergebruiken in al hun producten...

[IStealYourGun]

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 héél 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.

[Herko_ter_Horst]

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 23 juli 2024 08:35]

[Patriot]

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.

[IStealYourGun]

@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 23 juli 2024 08:35]

[johnbetonschaar]

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.

[Wim-Bart]

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.

[hiostu]

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.

[lennart111]

@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 )

[kidde]

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.

[daft_dutch]

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.

[johnbetonschaar]

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.

[HoppyF]

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.

[ILUsion]

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).

[HoppyF]

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.

[Blokker_1999]

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.

[.joeri.]

Of het gebruik van een hardwareklok of RTC kan dit probleem ook wel voorkomen lijkt me?

[Carbon]

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).

[Anoniem: 295700]

Programma's die gebruik maken van de datum en tijd zijn 1 van de moeilijkste om te maken.

[Anoniem: 34095]

zouden wel het best getest moeten worden, veel zaken hangen af van een kalender/tijd, daar leeft men mee.

[Spookie]

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?

[Quipeace]

Door de datum een dagje vooruit te zetten...?

[DJT88]

gewoon de klok vooruit zetten natuurlijk...

[Dooxed]

Je kan toch de datum even vooruit zetten en dan controleren of het wel of niet werkt?

[Krentenbol]

Gewoon even de datum veranderen in de instellingen. Wel even automatisch synchroniseren (als dat er is?) uitzetten

[Frigolamptje]

Hoewel sommigen er licht overgaan vind ik een betrouwbare wekker één van DE basisfuncties van een gsm/smartphone waar velen ook op betrouwen. Het is eigenlijk belachelijk dat je daar niet op kan vertrouwen bij zo'n toestel, gelijk wat het OS is! Zet zelf twee verschillende alarmen als ik moet opstaan, hoewel mijn Nexus One mij voorlopig nog nooit in de steek heeft gelaten (wat vroeger met winmo 6.5 ook niet altijd het geval was). Vind het echt een afknapper als ik moet vaststellen dat mijn alarm heeft gefaald, zo heb je het gevoel dat je op niets kan vertrouwen aan je telefoon.

[SgtElPotato]

Ja baas ik ben te laat omdat mijn telefoon uit was gevallen, en daardoor de wekker niet afging. Wat je krijgt te horen hoogstwaarschijnlijk: Koop een echte wekker.

Het is leuk dat er een wekker op je telefoon zit, maar het is geen basisfunctie van je telefoon. Ook zijn er een aantal scenario's te bedenken waardoor die het niet meer kan doen, en je dus niet gewekt word.
Koop een wekker op stroom. Een echte wekker.

Een goedkope wekker met een luide toon kost tegenwoordig geen 10 euro meer.

[Bacchus]

Nee, de electriciteitsvoorziening is lekker betrouwbaar. Nog beter dus een èchte Wekker!

[3dfx]

Ik had al in de jaren '80 een wekker op stroom met een batterij als backup?
En die worden nog steeds gemaakt en verkocht, dus waarom zo'n (lelijk/groot) tikkend ding naast je bed zetten dat je steeds zelf moet opwinden?

[Blokker_1999]

Maar de batterij dient enkel voor het geheugen, met batterij erin zal de wekker niet afgaan als er geen stroom is.

[3dfx]

Ja, bij exemplaren met een knoopcelbatterij misschien, maar ik heb het over 1 met een 9-voltbatterij als backup.

[Anoniem: 80487]

Ik ook, en die houd de wekker niet aan als je de stekker uit de muur trekt.
Ook die 9Volt batterij doet niets meer dan de tijden en andere settings onthouden.

[Denni]

Hier ben ik het helemaal mee eens. Het is dat ik lekker uit wou slapen 1 en 2 januari maar anders had ik gegarandeerd een college gemist. Dit is inderdaad een belangrijke basisfunctie die gewoon niet mag falen. Nou begrijp ik dat een bug die je als buitenstaander niet kunt begrijpen er altijd wel in kan sluipen(zo had en heeft Android zijn SMS bug..), maar als je voor je studie, afspraak of werk niet wordt gewekt kunnen mensen toch wel in de problemen komen.. Hopelijk fixen ze dit zodat het niet nog een keer(volgend jaar ofzo?) voorkomt..

[testaankoop]

Lol right, dat Tweakers.net geen negatief Android nieuws publiceert, betekent niet dat andere sites ook oogkleppen ophebben .

Ik heb zelf een Galaxy S met xxjpu rom en nog steeds heb ik last van de zwaaaaar irritante bug dat mijn smsjes bij de verkeerde mensen belanden. Echt heel vervelend, zo heb ik m'n voormalig werkgever al vaak verteld dat ik van hem hou blijkbaar en heb ik m'n neefje al 2 keer gestuurd naar de KVK en ABN Amro.

Het vervelende is dat mensen vaak ook niet terugreageren en het gewoon vergeten, zodat je werkelijk geen idee hebt dat het weer verkeerd is gegaan.
En sinds gisteren heb ik besloten dat de situatie niet meer werkbaar is en heb ik een losse iPhone 4 32gb besteld via Vodafone.

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

[Frigolamptje]

Dat is inderdaad verschrikkelijk irritant, maar als je verder tevreden bent van de Galaxy S, dan kan je het simpel verhelpen door bijvoorbeeld Handcent of Chomp SMS te installeren. Voor zover ik merk worden de berichten daar wel toegewezen aan de juiste nummers, de standaard sms client is sowieso al niet te goed. Los daarvan is het zeker onaanvaardbaar dat er zo'n bug aanwezig is.

[testaankoop]

Ja heb ik al eens eerder gehoord, maar ik heb er weinig vertrouwen meer in, plus dat ik reeds 750e heb betaald voor een iPhone 4, dus de Galaxy S leg ik in de kast of misschien installeer ik die als back-up navigatiesysteem in de auto. Alhoewel, de GPS is ook niet echt om over naar huis te schrijven.

[Bert2000]

vaag, ikzelf en al mn vrienden hebben dit nooit meegemaakt

[testaankoop]

Ja het vervelende is dus dat het jou ook overkomen kan zijn, maar dat je het nooit zult weten...

Dat ene meisje wiens nummer je had gekregen in de kroeg en je smste maar die nooit meer heeft gereageerd of een smsje naar die ene vriend die gisteren helemaal beurs was van een fietsvakantie, met de vraag of hij even naar het postkantoor wilt fietsen en een pakketje voor je op wilt halen omdat jij dubbel ligt van het lachen.

Misschien verwacht je in die situaties geen sms terug of beter gezegd, is het plausibel dat er niet geantwoord wordt en laat je het al snel voor wat het is. Maar de kans is dus nadrukkelijk aanwezig dat het gewoon een dikke bug is en die mensen je sms niet hebben gekregen.

Ik verstuur dagelijks gemiddeld 20 tot 30 smsjes, daar hoeven er maar 1 of 2 verkeerd verstuurd te worden om een vervelende situatie te creëren. En daar pas ik voor.

[Danfoss]

Dus je geruikt een niet officiele rom op je android en dan klaag je over bugs?
Goh.. Misschien is er wel een reden dat je deze rom niet via kies op je telefoon kunt krijgen?

Tip, misschien even upgraden naar de laatste door samsung gesupporte rom...

[testaankoop]

Goh, misschien moet je niet voorbarige conclusies trekken en misschien kan je accepteren dat er een hele dikke bug zit in de SMS client van Google Android.

1. Ik heb deze ROM gekregen van de reparatiedienst van Samsung.
2. Vanaf 2.1 tot en met 2.2.1 heb ik al last van deze "feature".
3. Toestel is reeds 3 keer omgeruild door Samsung.
4. Er zijn bijzonder veel mensen die berichten over dit probleem.
5. Zelfs Engadget heeft aan de bel getrokken bij Google over dit probleem.

Maar ik zal je tip in gedachten houden, downgraden naar 2.1 zal vast alle problemen oplossen.

[Anoniem: 380275]

Ach bij Android is het toch ook zo dat de wekker het soms laat afweten of dat het smsen dan weer onbetrouwbaar is en wel van zulk niveau dat je sms op Android best achterwege zou laten.

Bron

Maar ja van Android verbaasd me dat dan weer niet. Bij iOS zou dit inderdaad echt niet mogen. Dit is al de tweede keer op korte tijd dus hoog tijd er een paar koppen rollen bij quality control daar.

[Carbon]

Dit soort problemen zijn helaas niet beperkt tot de iPhone.
Vorige week ging op GSM toestel (Samsung Star) van mijn vrouw het herhalend alarm niet af. Alles stond goed ingesteld, maar de volgende dag exact hetzelfde probleem.
Oplossing? Alarm wissen en opnieuw aanmaken.

Volgens mij is dit het gevolg van de nieuwe/aankomende generatie programmeurs die het wiel opnieuw proberen uit te vinden met als gevolg dezelfde bugs als 25 jaar geleden.
Ik vrees dat consumenten de komende jaren vaker tegen dit soort (domme) bugs zullen aanlopen.

[Reactie gewijzigd door Carbon op 23 juli 2024 08:35]

[BastiaanN]

Ik denk eerder dat dit nu een van de nadelige effecten is van concurrentie. Iedereen probeert zo snel mogelijk een high-end toestel op de markt te zetten zodat de afdeling marketing iedereen lekker kan maken met de high-end specs. Foutloos werken bestaat niet, maar snel en foutloos werken al helemaal niet

En bovenstaande wordt tegenwoordig door het grote gros gewoon geaccepteerd. Bij een van mijn vorige werkgevers waar ik als programmeur in dienst was ging de voorkeur ook uit naar het optijd opleveren van het product, soms ten koste van kwaliteit.

[Wim-Bart]

1 van de redenen waarom ik ook gestopt ben met software ontwikkelen. Softwareleveranciers zijn per definitie een soort oplichters.

[Xthemes.us]

Weet niet hoe dat bij de opleidingen in het buitenland in elkaar steekt, maar de huidige opleidingen in Nederland laten je zeker niet het wiel opnieuw uitvinden, en als dat wel het geval is dat juist om aan te tonen hoe moeilijk het is om het origineel goed te dupliceren.

Datums en tijden zijn gewoon erg lastig.. een week kan zich in twee jaren bevinden, maanden hebben ongelijke lengtes, één keer in de vier jaar heeft een jaar zo maar een dag er bij. En dan van die dingen zoals een minuut die geen 100 seconden maar 60 seconden duurt en dergelijke.. absoluut een nachtmerrie om mee te werken. Vandaar dat de programmeur in het geval van datums altijd zoveel mogelijk gebruik maakt van bestaande functionaliteit om tijden te berekenen.

Echter is dit een stukje van het OS zelf, dus dat is de basis.. en dan heb je weinig te lenen. Vraag me wel af of OS X gebruikers hier geen last van hebben, lijkt me toch dat ze de basis van OS X voor dit soort dingen in iOS gebruiken? Wellicht niet gedaan door licenties problemen dan..

[Reactie gewijzigd door Xthemes.us op 23 juli 2024 08:35]

[M.M]

Ho, ho! Een jaar krijgt een extra dag als het jaartal deelbaar is door 4, maar niet als het jaartal deelbaar is door 100, maar weer wel als het jaartal deelbaar is door 400.

[anandus]

Op 3 januari zou de wekfunctie weer werken als vanouds.

Zoals je kan lezen heeft de wekker het soms niet gedaan.

Wat blijkt:
De wekfunctie die op 3 januari is ingesteld (dus na middernacht), die wekkers deden het wel prima.
De wekfunctie die vóór 3 januari (dus voor middernacht) is ingesteld, die zijn niet afgegaan.

Althans, ik geloof dat dat het geval is.

Ze hadden dat wel iets duidelijker mogen communiceren, want nu leek het alsof wekkers die ingesteld waren voor 3 januari het gewoon zouden doen.

[Reactie gewijzigd door anandus op 23 juli 2024 08:35]

[Earry]

Nee, ik heb mijn wekker rond 2:00 vannacht ingesteld maar hij ging vanochtend niet af.

[cyclone]

Misschien had je eerst even mijn reactie moeten lezen, wekker gezet NA 24.00 (dus op 3 jan) en deed het dus niet vanochtend om 07.00.

Foute aanname dus.

[Joeri Harleman]

Met de oudere versie van iOS werkte het prima. Ik kreeg om 0:00 een bericht dat mijn domeinen binnen zoveel dagen verlopen..

[jip_86]

Dat heeft toch niets met de wekker te maken? Neem aan dat je dat in je agenda zet?

[Joeri Harleman]

Nee hoor, heb dat via de 'Timer' gedaan in de 'Klok' applicatie.. Werkte prima. Ik gebruik de agenda niet ivm synchronisatieproblemen tussen 2 computers. Overstappen van hoster moest gebeuren in het nieuwe jaar, en 2 februari om 0.55 werd m'n abbonement bij de oude hoster automatisch verlengt. 's Avonds om 9 uur de timer gezet en kreeg om 0:00 bericht.

[Patriot]

De timer? Die telt toch gewoon af? Dat heeft niks met tijd en datum te maken, is gewoon een kookwekker.

[Keypunchie]

Is er iets mathematisch raars met de weektelling ofzo dit jaar? Want mijn Things wilde ook al geen scheduled tasks doen voor de laatste week van 2010, nu deze bug weer met de iPhone.

Ik heb geluk gehad dat ik kon uitslapen dit weekend, maar normaal vertrouw ik op het alarm van mijn telefoon (en dat ging met zomertijd dus al mis). Potdorie, Apple, hoe moeilijk kan dit zijn?!

[Blokker_1999]

Laatste week is week 53, daar kan slecht geprogrammeerde software op flippen omdat iedereen weet dat een jaar slechts 52 weken telt.

[Carbon]

omdat iedereen weet dat een jaar slechts 52 weken telt.

ISO Weeknummers lopen van 1-53

[testaankoop]

Het vervelende is, dat als Tweakers.net niet je enige Techblog was, je dit probleem zeer waarschijnlijk niet zou hebben gehad .
Van Engadget, Gizmodo en 9to5Mac op 30 en 31 december;

"We're aware of an issue related to non repeating alarms set for January 1 or 2. Customers can set recurring alarms for those dates and all alarms will work properly beginning January 3."

Let wel, ik zeg absoluut niet dat het niet een smerige en kansloos domme bug is, dat is het namelijk wel, helemaal omdat de oudere versies van iOS het niet hebben.

[Toff]

Je zult maar dagelijks diverse techblogs moeten raadplegen om de integriteit van je wekker te kunnen waarborgen...

Het had wel mooi geweest als iPhone-bezitters een SMS-berichtje hadden gehad over dit probleem, dat blijkbaar vantevoren al bekend was.

[testaankoop]

Dat zeg ik toch ook niet? Het is een kansloze bug, niet heel handig, maar ook niet echt een groot probleem aangezien de twee dagen die eronder leden, in het weekend vielen. En als je dan toevallig de andere techblogs leest, had je er rekening mee kunnen houden, dit nieuwsitem is een beetje boter na de maaltijd.

[Neko Koneko]

Haha, bij Apple hebben ze geen zin om in het nieuwjaarsweekend vroeg op te staan

[Hengst]

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.

aan de ontwerper van deze functionaliteit

[frickY]

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.

[DarkTemple]

We zitten nu nog in week 53 van 2010.

Week 52

[sharky_]

* 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.

[dasiro]

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.

[Anoniem: 178962]

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.

[sampoo]

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

[_AvA_]

En wie zegt dat Apple tijdens het programmeren rekening houdt met ISO normen?

[CyBeR]

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.

[Zapato]

Dat mag je toch wel hopen.

[mad_max234]

52 x 7 = 364

[stresstak]

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.

[roy-t]

Een jaar heeft 365 dagen, dus dit is nog week 53, niet week 52, daar reageerde mad_max234 op.

[Anoniem: 144946]

Nee, de zaterdag en zondag horen nog bij week 52 van het vorige jaar. Maandag begint week 01.

[Reactie gewijzigd door Anoniem: 144946 op 23 juli 2024 08:35]

[humbug]

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.

[kidde]

Maar welke prutsert maakt er nu een "eenmalige" wekker die zich iets van het weeknummer aantrekt?

[Anoniem: 63628]

Mensen met een onregelmatig patroon? Alle studenten en leerlingen zo'n beetje.

[gregoire]

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.

[WimBarelds]

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.

[michiel_hc]

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.

[johnbetonschaar]

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.

[Anoniem: 364852]

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.

[To_Tall]

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.

[CyBeR]

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 23 juli 2024 08:35]

[johnkeates]

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.

[darkjeric]

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.

[johnkeates]

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.

[tabasco]

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...

[To_Tall]

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.

[PoweRoy]

helaas is flash niet alleen video, games, ads, menu etc

[johnbetonschaar]

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.

[antiekeradio]

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 geïnstalleerde programmatuur.

[johnbetonschaar]

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.

[Asteryz]

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.

[Guru Evi]

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.

[Wim-Bart]

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

[Ocelot]

@Wim-Bart
Als het een SD kaart is kan dat best.

[Benne]

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.

[z.jeroen]

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.

[gregoire]

Inderdaad, bij apple moet je eerst activeren voor je ipad iets doet.

[Anoniem: 19339]

Inderdaad, bij apple moet je eerst activeren voor je ipad iets doet.

En het verschil daarin met Windows is...?

[Roeland]

30-dagen trial

[Mars Warrior]

Nee, en dat lijkt voor elk nieuwjaar te gelden als je hier kijkt.

[aikebah]

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

[humbug]

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.

[XyritZz]

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

[Smht]

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.

[x3n0ph0n]

You don't want to work on new year... There's an app for that!

[Djerique]

2011 wordt het jaar van Android! Dus bedankt Apple voor deze fail

[Anoniem: 380275]

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.

[Anoniem: 384399]

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 dáár gaat het over, in dit topic

[Anoniem: 380275]

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.

[Anoniem: 384399]

@WTF?: Ah ok, ik heb 'flat mode' aanstaan, dan krijg je dat

In dat geval is m'n post bedoeld voor die anderen die denken dat met wijzen het probleem minder erg wordt

[Benne]

En die zelfde sms komt gemiddeld op en iphone een uur later aan.

[Anoniem: 80466]

Vast:
http://www.zdnet.com/blog...-to-random-contacts/10796

[SteroiD]

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.

[Anoniem: 80466]

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...

[Anoniem: 312533]

De bug verdwijnt niet vanzelf, je hebt er alleen geen last meer van (voorlopig)

[martijnve]

Niemand heeft de bug ooit aan kunnen tonen, steeds meer mensen denken dat het gewoon user error is.

[Anoniem: 380275]

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?

[Anoniem: 63628]

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.

[RubenTheys]

De groei van iPhone bedoel je waarschijnlijk, waarmee ik het wel eens ben (als iPhone gebruiker, een zeldzaamheid ).

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 wél serieus wat tegengas krijgen in 2011.

[Thomas]

Er komt waarschijnlijk wel een grote groei in Android tablets! In 2011 zullen er namelijk versies van Android uitkomen die wel goed tablets ondersteunen .

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).

[trisje]

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.

[To_Tall]

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??

[MSalters]

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.