Apple: 'niet storen'-bug wordt automatisch verholpen
De 'niet storen'-feature die in iOS 6 zit ingebakken zal na 7 januari weer als vanouds werken, zo heeft Apple beloofd. Na de jaarwisseling bleek dat de functionaliteit, die geluiden van binnenkomende notificaties uitzet, ook buiten de ingestelde tijd geluiden dempt.
Op de site van Apple is een verklaring gepubliceerd waarin het probleem met de 'niet storen'-feature wordt erkend. De fabrikant laat weten dat Do Not Disturb buiten de ingestelde tijd blijft werken, waardoor gebruikers geluiden voor binnenkomende notificaties van bijvoorbeeld telefoongesprekken of berichten missen. Volgens Apple zal de functie na 7 januari weer normaal werken. Tot die tijd wordt geadviseerd om handmatig 'niet storen' uit te zetten. Een verklaring voor de bug werd niet gegeven.
De problemen met 'niet storen' verschenen na de jaarwisseling, toen gebruikers op verscheidene fora en sociale media lieten weten dat de functionaliteit zichzelf niet automatisch uitschakelde. De functionaliteit werd door Apple geïntroduceerd in iOS 6 en kan er bijvoorbeeld voor zorgen dat gebruikers 's nachts niet gestoord worden door geluiden van binnenkomende notificaties.
Het is niet de eerste keer dat iOS-software met problemen kampt na een jaarwisseling. Twee jaar geleden gebeurde dat ook al, toen bleek dat ingestelde wekkers niet langer functioneerden. Ook toen liet Apple weten dat de functionaliteit zichzelf zou herstellen, maar toch bleef een aantal gebruikers nog last hebben van de bug.
Reacties (75)
Het is ook gewoon super lastig om met alles rekening mee te houden als het om tijd gaat. Wintertijd, zomertijd enzovoort!
Ik ken de functionaliteit niet, maar ik neem aan dat je gewoon per dag kun instellen hoelaat het an en uit moet. Wat maakt dan de zomertijd, uur tijdsverschil, schikkeljaar e.d. uit? Je kunt toch gewoon de tijd uitlezen, die is elke dag hetzelfde en als het moment passeert zetj e de functionaliteit aan of uit.
Ik heb het idee dat er veel code wordt geschreven die volledig zinloos is. Allemaal onnodige complexiteit. Hetzelfde als met die wekker bug, waarom zou je met alle mogelijke variabelen rekening houden als de wekker om 8uur moet afgaan. Kwestie van checken of het 8uur is, indien ja, wekker aflaten lopen (maar misschien ben ik te simpel
)
Ik heb het idee dat er veel code wordt geschreven die volledig zinloos is. Allemaal onnodige complexiteit. Hetzelfde als met die wekker bug, waarom zou je met alle mogelijke variabelen rekening houden als de wekker om 8uur moet afgaan. Kwestie van checken of het 8uur is, indien ja, wekker aflaten lopen (maar misschien ben ik te simpel
)De hardware moet uit de wake komen, hierdoor moet men van te voren aangeven over hoeveel uur je toestel moet ontwaken.
Als hierbij geen rekening wordt gehouden met zomer/winter tijd, wordt jou telefoon te vroeg of te laat ontwaakt en zal hij falen.
Tuurlijk kan je je device ook de hele tijd laten pollen
while(true)
if(wekkerTijd > huidigeTijd)
ga af
Maar dat lijkt mij niet de meest goedkope oplossing (batterij enzo, je mobiel blijft dan actief).
@Carino: Requires data connection
@Blokker_1999: Als iemand mij belt moet mijn telefoon ook uit de idle stand komen, dus nee, tuurlijk doet hij dingen op de achtergrond.
Als hierbij geen rekening wordt gehouden met zomer/winter tijd, wordt jou telefoon te vroeg of te laat ontwaakt en zal hij falen.
Tuurlijk kan je je device ook de hele tijd laten pollen
while(true)
if(wekkerTijd > huidigeTijd)
ga af
Maar dat lijkt mij niet de meest goedkope oplossing (batterij enzo, je mobiel blijft dan actief).
@Carino: Requires data connection
@Blokker_1999: Als iemand mij belt moet mijn telefoon ook uit de idle stand komen, dus nee, tuurlijk doet hij dingen op de achtergrond.
[Reactie gewijzigd door XiniX88 op donderdag 3 januari 2013 08:48]
de meest eenvoudige oplossing hierin zal Apple's eigen Push notificatie systeem zijn... Enige wat je hoeft te doen is een nieuw bericht type in het leven te roepen die nooit zichtbaar zal worden maar wel applicaties (of enkel het toestel) even wakker kunnen maken... dan heb je verder geen enkele logica op de telefoon nodig.
probleem is dan echter wel dat een bericht gemist kan worden en dan krijg je selectief niet goed werkende software...
probleem is dan echter wel dat een bericht gemist kan worden en dan krijg je selectief niet goed werkende software...
Je denkt nu toch niet dat wanneer je telefoon in standby staat dat deze helemaal geen dataverwerking meer doet mag ik hopen. De CPU blijft gewoon op laag tempo werken en de achtergrondprocessen blijven netjes hun ding doen. De applicatie moet gewoon op bepaalde intervallen kijken of er actie ondernomen moet worden en als de tijd gekomen is alles doen om die actie ook te laten uitvoeren. Er moet helemaal van te voren niet gekeken worden hoe lang het nog moet duren.
het bereik kan soms toch weg vallen... dan kan je nog zo'n goede data verbinding hebben, push wordt dan gewoon niet ontvangen.
uiteraard kan het allemaal netjes met achtergrondprocessen etc, maar het zal me niks verbazen als ze voor een centraal beheerde oplossing gekozen hebben...
uiteraard kan het allemaal netjes met achtergrondprocessen etc, maar het zal me niks verbazen als ze voor een centraal beheerde oplossing gekozen hebben...
Ik denk dat je je daarin vergist. Ongeacht hoe de telefoon werkt in standby modus of do not disturb mode is het vrijwel zeker dat er een timer gebruikt wordt die voor de volle periode ingesteld worden. Die zijn veel efficiënter dan iedere minuut een timer af te laten gaan en dan kijken hoe laat het is en of de do not disturb mode uitgeschakeld hoeft te worden. Dat is dan iedere minuut verspilde CPU en compleet nutteloos omdat je al exact weet wanneer de handeling uitgevoerd moet worden.
Jij zet 's avonds ook niet de wekker om je de hele nacht door iedere minuut wakker te maken zodat je iedere minuut kan bepalen of je al op moet staan. Die stel je in om af te gaan wanneer je op moet staan want dat weet je van te voren al.
Jij zet 's avonds ook niet de wekker om je de hele nacht door iedere minuut wakker te maken zodat je iedere minuut kan bepalen of je al op moet staan. Die stel je in om af te gaan wanneer je op moet staan want dat weet je van te voren al.
Hoe weet die timer dan dat er X uur verstreken is? 
exact er is een mechanisme dat om de zoveel tijd 'alarm aangezet + interval >= tijd nu' uitrekent
exact er is een mechanisme dat om de zoveel tijd 'alarm aangezet + interval >= tijd nu' uitrekent Er is een algoritme die de systeemklok moet bijhouden. Waarschijnlijk kan in dat algoritme een event worden gekoppeld aan een bepaalde tijd. Dat is dus veel efficiënter dan dat je zelf een while loop programmeert. Een while loop gooit je CPU verbruik omhoog en slurpt daarmee je batterij leeg. De body van de while loop wordt afhankelijk van de beschikbare processorkracht honderden malen uitgevoerd binnen een seconde, terwijl het systeemklokalgoritme slechts eenmaal per seconde controleert of het tijd is om het event te triggeren.
Daarbij is het verstandiger om vooraf de formule 'alarm aangezet + interval' te berekenen omdat je dan uiteindelijk alleen nog maar hoeft te controleren of de huidige tijd gelijk is aan de alarm tijd, scheelt weer wat ALU gebruik.
Daarbij is het verstandiger om vooraf de formule 'alarm aangezet + interval' te berekenen omdat je dan uiteindelijk alleen nog maar hoeft te controleren of de huidige tijd gelijk is aan de alarm tijd, scheelt weer wat ALU gebruik.
Eigenlijk, blijft de baseband chip draaien, deze zeer energie zuinige chip word ingezet voor push tel sms etc. en zelfs geofencing, zelfde geld voor muziek, enkel de decoder AIO chip blijft aanstaan en daarom is het mogelijk zo lang muziek te luisteren op je device.
Dat is ook het mooie van het iOS framework, je kan je applicatie niet in de achtergrond laten draaien ze worden altijd gesloten, alleen apple heeft API's geschreven voor die decoder chip en baseband chip etc waardoor het mogelijk is dat de app muziek blijft spelen in de achtergrond zonder daadwerkelijk cpu kracht te verslinden
Dat is ook het mooie van het iOS framework, je kan je applicatie niet in de achtergrond laten draaien ze worden altijd gesloten, alleen apple heeft API's geschreven voor die decoder chip en baseband chip etc waardoor het mogelijk is dat de app muziek blijft spelen in de achtergrond zonder daadwerkelijk cpu kracht te verslinden
Dit probleem heeft niets te maken met zomer/winter tijd.
Een degelijke implementatie is bestand tegen jaarwisselingen, dwz ziet niet eens welk jaar het is voor timer afhandelingen en zo.
Voor eventuele taken schedule je een wakeup na bv 'x' seconden (waar bij x afhankelijk is van de 1e taak die je moet doen). Na het uitvoeren ga je weer in sleep, waarbij je eventueel een nieuwe wakeup instelt voor een volgende taak.
Hoewel het niet duidelijk is of het te maken heeft met een eerder probleem is het wel verdacht dat het weer op eenzelfde moment optreed.
Een degelijke implementatie is bestand tegen jaarwisselingen, dwz ziet niet eens welk jaar het is voor timer afhandelingen en zo.
Voor eventuele taken schedule je een wakeup na bv 'x' seconden (waar bij x afhankelijk is van de 1e taak die je moet doen). Na het uitvoeren ga je weer in sleep, waarbij je eventueel een nieuwe wakeup instelt voor een volgende taak.
Hoewel het niet duidelijk is of het te maken heeft met een eerder probleem is het wel verdacht dat het weer op eenzelfde moment optreed.
ware het niet dat zomer/wintertijd toch echt maanden verwijderd ligt van 1 januari..
Of ik nou met iemand afspreek over 5 uur of om 14:30 in beide gevallen moet ik klok kijken om te zien of het tijd is om in actie te komen...Tuurlijk kan je je device ook de hele tijd laten pollen
while(true)
if(wekkerTijd > huidigeTijd)
ga af
Oftewel je moet hoe dan ook pollen of zelf tellen, dat systeem kan nooit magisch weten dat er ineens 5 uur voorbij is gegaan...
Elk modern RealtimeClock IC kan gewoon een simpele IRQ doen om een van te voren geprogrammeerde tijd, zo moeilijk is dat nou ook weer niet.
...en daarvoor heb je als ik het zo zie geen datum nodig. Alleen de dag van de week en de tijd. Dat is volledig onafhankelijk van schrikkeljaren, zomer- en wintertijd en wat al niet. Ik heb het vermoeden dat Apple ergens toch iets met de datum doet en dat het daar fout gaat. Waarschijnlijk iets met een weeknummer ofzo, aangezien het de 7e (eerste volledige week van het jaar) opgelost isDe hardware moet uit de wake komen, hierdoor moet men van te voren aangeven over hoeveel uur je toestel moet ontwaken.
Waarom werk je niet bij apple als je het zo goed weet?Ik ken de functionaliteit niet, maar ik neem aan dat je gewoon per dag kun instellen hoelaat het an en uit moet. Wat maakt dan de zomertijd, uur tijdsverschil, schikkeljaar e.d. uit? Je kunt toch gewoon de tijd uitlezen, die is elke dag hetzelfde en als het moment passeert zetj e de functionaliteit aan of uit.
Ik heb het idee dat er veel code wordt geschreven die volledig zinloos is. Allemaal onnodige complexiteit. Hetzelfde als met die wekker bug, waarom zou je met alle mogelijke variabelen rekening houden als de wekker om 8uur moet afgaan. Kwestie van checken of het 8uur is, indien ja, wekker aflaten lopen (maar misschien ben ik te simpel
reactie op watercoolertje hieronder:
ja, alsof zijn argument "ik ken de functionaliteit niet, maar heb wel een mening" een valide punt is om meteen het geheel af te doen alsof het makkelijk is om het even recht te breien. Als dat waar zou zijn, dan zou het immers al meteen gefixed worden, lijkt me.
Zijn tweede punt "ik heb het idee dat er veel code wordt geschreven die volledig zinloos is" Dat is onderbuik gevoel en imo totaal off topic.
Voor mij betekent dat dus: de beste stuurlui staan aan wal.
[Reactie gewijzigd door Shark.Bait op donderdag 3 januari 2013 11:24]
Misschien omdat Apple geen vacature had open staan voor klok-specialist.
Lekker simpel om elk argument zo weg te blazen trouwens. Ow jij hebt commentaar op merk X, nou waarom werk je er niet als je het zo goed weet, en hoppa discussie naar de kloten...
Lekker simpel om elk argument zo weg te blazen trouwens. Ow jij hebt commentaar op merk X, nou waarom werk je er niet als je het zo goed weet, en hoppa discussie naar de kloten...
Maakt niet uit of het "super lastig is". Het moet gewoon werken. Wat heb ik aan een telefoon die niet overgaat als je gebeld wordt?
Als het te "super lastig is" moeten ze het niet vrijgeven. Aan halfwerkende functies hebben we niets.
Als het te "super lastig is" moeten ze het niet vrijgeven. Aan halfwerkende functies hebben we niets.
Stel je niet aan halfwerkende functies, werkt prima zit alleen een bug in van een week.
Als iedereen zo kieskeurig is zouden er een stuk minder mobieltjes verkocht worden van de concurent.
Als iedereen zo kieskeurig is zouden er een stuk minder mobieltjes verkocht worden van de concurent.
Een functie die een week per jaar niet werkt is inderdaad een 'halfwerkende functie'. Als het op het favoriete merk aankomt van een fanboy is blijkbaar alles geoorloofd...
Volgens mij ging de klok niet vooruit of achteruit rond oud en nieuw. Als de wekker nu 0x of 2x afgaat bij zomer (er is geen 2:30) of wintertijd (er is 2x 2:30), dan kan ik me nog enigsinds een 'lastige' uitdaging indenken...(...) Wintertijd, zomertijd enzovoort!
Nee, maar de dag en maand wel. Na 31 december komt 1 januari. Als er geen jaartal bij staat, gaat de kalender dus achteruit.Volgens mij ging de klok niet vooruit of achteruit rond oud en nieuw.
Als de code ongeveer werkt als "als de eindtijd eerder is dan de begintijd, is de eindtijd in de volgende dag", en "de volgende dag = huidige dag +1", maar in dat laatste stukje wordt geen rekening gehouden met dat 1 januari na 31 december komt, dan hang je.
Het zou slordig zijn, maar als je programmeert moet je aan alles denken, want uit zichzelf gebeurt er niets. Als er niet met een bepaald scenario rekening wordt gehouden (bijvoorbeeld een jaarwisseling), dan krijg je dit soort bugs.
Maar je mag verwachten dat een beetje programmeur zo'n achterlijke fout (geen rekening houden met jaartal of schrikkeljaar) toch echt niet maakt zeker niet als je bezig bent met een applicatie die draait om datum en tijden (als je nou echt nooit ermee te maken hebt en toevallig op 1 klein plekje ineens iets met datum moet doen, kan ik me nog wel er iets bij voorstellen, maar niet als je bezig bent met een applicatie die datum/tijd gebaseerd is.)
Tja, dat zou een stomme fout zijn. Maar het verklaard niet waarom hij vanaf 7 januari weer werkt. Want 2 januari > 1 janurari. Dan moet het probleem toch al "weg" zijn?
En waarom zou dit met dagen werken? Je kan toch om uur X op stil gaan en uur Y weer uit die modus, onafhankelijk van de dag?
En waarom zou dit met dagen werken? Je kan toch om uur X op stil gaan en uur Y weer uit die modus, onafhankelijk van de dag?
Hij werkt ook nog met weeknummers?
Ik vind het echt leuk dat je het uitlegt, maar volgens mij in mijn voorbeeld van 0x of 2x een 2:30 op dezelfde dag wel aan dat ik het probleem begrijp, gaat je wekker 0x of 2x af om 2:30? Als je zo nog programmert zonder jaartal, dan ben je een IT-er van NA het millennium-probleem dan. Hoe ongelovelijk klasiek is dát wel niet geweest.Nee, maar de dag en maand wel. Na 31 december komt 1 januari. Als er geen jaartal bij staat, gaat de kalender dus achteruit.
(...)
Het zou slordig zijn, maar als je programmeert moet je aan alles denken, want uit zichzelf gebeurt er niets. Als er niet met een bepaald scenario rekening wordt gehouden (bijvoorbeeld een jaarwisseling), dan krijg je dit soort bugs.
Apple hing ook al eerder op een uurtje tijdverschil met de wekker, volgens mij is er wat mis in hun tijd/datum objecten, als ze uberhaupt al code hergebruiken.
LOL, dat zijn inderdaad wel de moeilijkste dingen bij software ontwikkeling 
Dat vind ik flauwekul.
Als programmeur wordt je verwacht 'superlastige' problemen op te lossen, anders had iedereen wel kunnen programmeren. Daarnaast heeft het niks te maken met zomer/wintertijd, gezien we midden in de wintertijd zitten. Ik ben overigens zelf ook programmeur.
Begrijp me niet verkeerd, de bug bij Google wat betreft de missende December van pasgeleden is net zo prutserig.
Zo'n dingen komen gewoon voor omdat er ontzettend veel druk ligt op het team om zoveel mogelijk features erin te bouwen, met harde release dates. Bugs zijn onvermijdelijk, maar dit zijn wel grote flaters als je het mij vraagt.
Dat gezegd hebbende: Apple's reactie is logisch, de bug gaat vanzelf weg. Dat lijkt lui, maar het is natuurlijk niet makkelijk of nuttig om voor die tijd nog een fix te releasen. Het duurt enkele dagen voordat je je code volledig getest hebt, dan nog eens enkele dagen voordat je de update kunt verspreiden.
Als programmeur wordt je verwacht 'superlastige' problemen op te lossen, anders had iedereen wel kunnen programmeren. Daarnaast heeft het niks te maken met zomer/wintertijd, gezien we midden in de wintertijd zitten. Ik ben overigens zelf ook programmeur.
Begrijp me niet verkeerd, de bug bij Google wat betreft de missende December van pasgeleden is net zo prutserig.
Zo'n dingen komen gewoon voor omdat er ontzettend veel druk ligt op het team om zoveel mogelijk features erin te bouwen, met harde release dates. Bugs zijn onvermijdelijk, maar dit zijn wel grote flaters als je het mij vraagt.
Dat gezegd hebbende: Apple's reactie is logisch, de bug gaat vanzelf weg. Dat lijkt lui, maar het is natuurlijk niet makkelijk of nuttig om voor die tijd nog een fix te releasen. Het duurt enkele dagen voordat je je code volledig getest hebt, dan nog eens enkele dagen voordat je de update kunt verspreiden.
Helemaal mee eens. Ik zou tegen de iPhone-bezitters willen zeggen: geniet van je rust de komende dagen.
No pun intended.
No pun intended.
Er zit geen pun in je zin.
"Zo'n dingen"
Voorheen zag ik walgelijke zinsconstructies eigenlijk alleen bij Limburgers, maar ik zie het tegenwoordig steeds vaker voorbij komen.
Ben ik nou de enige die "Zo'n dingen" echt NIET vind kunnen en het ronduit onsmakelijk Nederlands vind?
Voorheen zag ik walgelijke zinsconstructies eigenlijk alleen bij Limburgers, maar ik zie het tegenwoordig steeds vaker voorbij komen.
Ben ik nou de enige die "Zo'n dingen" echt NIET vind kunnen en het ronduit onsmakelijk Nederlands vind?
Voor een super groot bedrijf met super veel resources denk ik dat dit probleem een eitje moet zijn. Dit geldt niet alleen voor Apple overigens.
Een supergroot bedrijf als Apple heeft zoveel resources/werknemers omdat ze nogal veel werk te verzetten hebben.
Het is niet zo dat er een paar honderd werknemers zitten te wachten op werk en dat ze, zodra er een bug gemeld wordt, erop kunnen springen.
Natuurlijk zijn er afdelingen welke continu aan het monitoren zijn of er kritische bugs gemeld worden, maar laten we eerlijk zijn, dat is deze niet.
Als ik een iPhone-bezitter zou zijn, zou ik hier niet echt wakker van liggen.
Maar ik vind het ook niet erg om een gesprek te missen, mijn telefoon staat eigenlijk altijd op stil.
Het is niet zo dat er een paar honderd werknemers zitten te wachten op werk en dat ze, zodra er een bug gemeld wordt, erop kunnen springen.
Natuurlijk zijn er afdelingen welke continu aan het monitoren zijn of er kritische bugs gemeld worden, maar laten we eerlijk zijn, dat is deze niet.
Als ik een iPhone-bezitter zou zijn, zou ik hier niet echt wakker van liggen.
Maar ik vind het ook niet erg om een gesprek te missen, mijn telefoon staat eigenlijk altijd op stil.
In je op een na laatste zin zit wel een leuke pun.
Als in eiPhone bedoel je?
De producten bij Apple zijn in verhouding tot de omzet en winst erg gelimiteerd dus jouw reactie slaat behoorlijk de plank mis.
Zomertijd/wintertijd is niks anders dan een verandering in tijdzone. De klok veranderd niet. Wat lastiger is zijn schrikkeldagen en -seconden. Vooral de schrikkelseconde is lastig, want die is niet algoritmisch bepaald.
Gezien het probleem zich op 31 december voordeed zou het best een incorrecte schrikkelseconde geweest kunnen zijn.
Gezien het probleem zich op 31 december voordeed zou het best een incorrecte schrikkelseconde geweest kunnen zijn.
zomertijd/wintertijd is wel even iets meer dan alleen een verandering in tijdzone.. schrikkeldagen is ook niet echt een probleem, maar ik ben het wel eens met je mbt die schrikkelseconde..
Iets meer als in: op dag X op Y uur moet de tijdzone veranderd worden naar Z. Veel meer dan dat mag het absoluut niet zijn, anders doe je het echt verkeerd. Het is namelijk alleen de weergave van tijd, en niet een verandering van de tijd.zomertijd/wintertijd is wel even iets meer dan alleen een verandering in tijdzone.
Tijdzone kan namelijk op willekeurige momenten veranderen, de systeem klok zal gewoon door moeten tellen en niet opeens een uur moeten verspringen. Sterker nog, systeem klok mag alleen vooruit gaan, en absoluut niet achteruit omdat tijdsberekingen dat negatieve getallen opleveren terwijl de tijd echt niet achteruit gegaan is. Om deze reden zal een goede NTP client secondes versnellen of vertragen om de tijd te corrigieren.
[Reactie gewijzigd door elmuerte op donderdag 3 januari 2013 11:25]
Bron: http://en.wikipedia.org/wiki/Unix_timeUnix time is a single signed integer number which increments every second, without requiring the calculations to determine year, month, day of month, hour and minute required for intelligibility to humans.
Je kunt het zo moeilijk maken als je zelf wilt
DST (daylight saving time) is lastiger dan je denkt, kijk hier maar eens naar
http://www.youtube.com/watch?v=84aWtseb2-4
(reactie op KvanSteijn)
http://www.youtube.com/watch?v=84aWtseb2-4
(reactie op KvanSteijn)
[Reactie gewijzigd door thalantis op donderdag 3 januari 2013 08:11]
Geweldig interessante video. Nooit geweten dat dit zo versnipperd was... Wat mij betreft > afschaffen die handel.
Maar dit topic gaat over de jaarwisseling, en dat heeft natuurlijk niets te maken met de DST. Ook een jaarwisseling is lastig te testen, zeker onder een betatest groep die zomers bezig is, maar dit zou op zich eruit te halen moeten zijn. En het is opmerkelijk dat iOS telkens weer moeite heeft met dit soort tijddingetjes...
Maar dit topic gaat over de jaarwisseling, en dat heeft natuurlijk niets te maken met de DST. Ook een jaarwisseling is lastig te testen, zeker onder een betatest groep die zomers bezig is, maar dit zou op zich eruit te halen moeten zijn. En het is opmerkelijk dat iOS telkens weer moeite heeft met dit soort tijddingetjes...
Idd: zal wel zwaar OT zijn maar dat hele zomer- / wintertijdgedoe is zo enorm achterhaald.
Toen de meerderheid der mensheid nog van 8 tot 5 actief was, was hier wellicht een energiebesparing te behalen. Maar aangezien we tegenwoordig van 6 uur 's ochtends tot 10 uur 's avonds actief zijn, is dit volstrekt nutteloos geworden.
Kijk nu naar deze tijd. Het is nu nog praktisch donker buiten (kwart voor 9). Als ik vanavond naar huis ga om 5 uur is het ook alweer donker. Wat is dan de besparing? Niks toch
?
Het omzetten van die klokken (waar zoals het filmpje bewijst ook geen enkele standaard voor is), is enkel tijdrovend, irritant en kost ons alleen maar geld (verloren tijd door instellen, vergissingen en de - weer ontopic - onvermijdelijke bugs in allerlei software).
Toen de meerderheid der mensheid nog van 8 tot 5 actief was, was hier wellicht een energiebesparing te behalen. Maar aangezien we tegenwoordig van 6 uur 's ochtends tot 10 uur 's avonds actief zijn, is dit volstrekt nutteloos geworden.
Kijk nu naar deze tijd. Het is nu nog praktisch donker buiten (kwart voor 9). Als ik vanavond naar huis ga om 5 uur is het ook alweer donker. Wat is dan de besparing? Niks toch
?Het omzetten van die klokken (waar zoals het filmpje bewijst ook geen enkele standaard voor is), is enkel tijdrovend, irritant en kost ons alleen maar geld (verloren tijd door instellen, vergissingen en de - weer ontopic - onvermijdelijke bugs in allerlei software).
Inderdaad, het is nu vooral voor de boeren en andere mensen die buiten werken. Maar ik zie ook niet helemaal in waarom die niet gewoon hun werktijden aanpassen, dan kunnen ze het ook wat flexibeler doen (bijv. per half uur). Maar het is tegenwoordig Europees bepaald dus ik zie ze dat niet zo 1-2-3 aanpassen.
[Reactie gewijzigd door GekkePrutser op donderdag 3 januari 2013 10:13]
De besparing zit in de zomertijd niet in de winter Want de winter tijd is de echte tijd.
Eerlijk gezegt ben ik juist voorstander van de zomertijd, want heb ik zelf meer aan een uurtje extra licht in de avond dan dat het al om 5 uur licht is want dan lig ik toch in mijn bed. En daarvoor wil ik best 2 keer per jaar 1 minuut besteden aan het verzetten van 2 klokken in huis, de rest gaat toch automatisch. Het enige wat ik me zou kunnen indcenken is dat het makkelijker zou zijn om die data gelijk te trekken over de gehele wereld.
Je bespaart dus door dat je in de zomer het licht een uur later aan kan doen.
Want de winter tijd is de echte tijd. Eerlijk gezegt ben ik juist voorstander van de zomertijd, want heb ik zelf meer aan een uurtje extra licht in de avond dan dat het al om 5 uur licht is want dan lig ik toch in mijn bed. En daarvoor wil ik best 2 keer per jaar 1 minuut besteden aan het verzetten van 2 klokken in huis, de rest gaat toch automatisch. Het enige wat ik me zou kunnen indcenken is dat het makkelijker zou zijn om die data gelijk te trekken over de gehele wereld.
Je bespaart dus door dat je in de zomer het licht een uur later aan kan doen.
Daarom zijn er al talloze libraries die hier wel correct mee om kunnen gaan. Mijn vermoeden is dus dat Apple het wiel opnieuw heeft uitgevonden, maar hem allen niet helemaal rond heeft gemaakt.
Als je de datum handmatig wijzigt naar 7 januari zet is het inderdaad verholpen
Vreemd 1 jan had ik hier last van maar sinds gister werkt het weer prima. Verder blijft het een raar verhaal. Wat maakt 2013 zo speciaal dat een tijdgebonde (niets met datum te maken) functie niet meer werkt??
Verder mij benieuwen of straks zomertijd of 2014 dan ook niet aan de orde zijn..
Verder mij benieuwen of straks zomertijd of 2014 dan ook niet aan de orde zijn..
[Reactie gewijzigd door ultimasnake op donderdag 3 januari 2013 08:27]
Het zal iets met laatste/'1e week" van het jaar te maken hebben, die eigenlijk al de 2e week is.
Ook niet echt logisch bij een functie die NIKS met weken (of jaartallen of maanden) te maken heeft, maar enkel met wat de klok op de telefoon DIT moment weergeeft...
Wel beetje makkelijke weg zeg. Ondanks dat er een work-around schijnbaar is lijk me toch allerminst dat je zulke problemen oplost. Ik zag al inderdaad dat een aantal hier de datum naar 7 januari verplaatst dat die het niet meer doet. Probleem kan ik ongeveer weg gokken...deze week is week 53/week 01, bij oa opvragen via PHP met date("Y") krijg je 2012 ipv 2013. Door gebruik te maken van unix tijd date("o") krijg je wel de correcte jaar. Liep er vorige week tegenaan 
Terugkomend op de reactie van Apple, mijn klanten zouden het niet accepteren als ik zou zeggen, wacht maar even een weekje dan doet alles het weer...
Terugkomend op de reactie van Apple, mijn klanten zouden het niet accepteren als ik zou zeggen, wacht maar even een weekje dan doet alles het weer...
Maar zo te zien is jouw bug server-side op te lossen en heeft dat geen betrekking op een fix verspreiden over miljoenen devices. Een proces dat waarschijnlijk net zo lang duurt als gewoon 4 dagen uitzitten.
Begrijp me niet verkeerd, het is slordig. Maar geef toe; is het nou écht zo'n kritieke feature?
Daarbij kan een gevestigd multinational als Apple deze 'arrogante' houding gewoon aannemen natuurlijk, daar ze genoeg in reserve hebben en ze dit waarschijnlijk niet eens een cent zal schelen.
Begrijp me niet verkeerd, het is slordig. Maar geef toe; is het nou écht zo'n kritieke feature?
Daarbij kan een gevestigd multinational als Apple deze 'arrogante' houding gewoon aannemen natuurlijk, daar ze genoeg in reserve hebben en ze dit waarschijnlijk niet eens een cent zal schelen.
[Reactie gewijzigd door jfversluis op donderdag 3 januari 2013 08:58]
De bug die ik benoem is inderdaad in mijn geval server side. Echter probeer ik voor mensen enigszinds te beschrijven wat er mis kan gaan. Uit eindelijk maakt het geen bal uit of ik nou op een server zit op een device, ze hebben allemaal dates...
Ik denk dat het niet aan mij is om het kritiek te beschouwen. Zelf heb ik geen iPhone dus kan er weinig over zeggen. Wat ik wel kritiek vind, al is het voor een paar dagen is:
De fabrikant laat weten dat Do Not Disturb buiten de ingestelde tijd blijft werken, waardoor gebruikers geluiden voor binnenkomende notificaties van bijvoorbeeld telefoongesprekken of berichten missen.
Stel je hebt een bedrijfstelefoon, en in het slechtste geval stond die voor een gehele dag in die stand (ingesteld), heb je dus de gehele dag geen telefoontjes of berichten die je hoort. Dat zou ik niet willen als ondernemer...zelfs niet als het iedere dag tussen een klein tijdsmoment is...
En inderdaad multinational met arrogante houding, worden ze uiteindelijk nog wel een keer op afgerekend.
Ik denk dat het niet aan mij is om het kritiek te beschouwen. Zelf heb ik geen iPhone dus kan er weinig over zeggen. Wat ik wel kritiek vind, al is het voor een paar dagen is:
De fabrikant laat weten dat Do Not Disturb buiten de ingestelde tijd blijft werken, waardoor gebruikers geluiden voor binnenkomende notificaties van bijvoorbeeld telefoongesprekken of berichten missen.
Stel je hebt een bedrijfstelefoon, en in het slechtste geval stond die voor een gehele dag in die stand (ingesteld), heb je dus de gehele dag geen telefoontjes of berichten die je hoort. Dat zou ik niet willen als ondernemer...zelfs niet als het iedere dag tussen een klein tijdsmoment is...
En inderdaad multinational met arrogante houding, worden ze uiteindelijk nog wel een keer op afgerekend.
Ik wil geen eindeloze discussie aanzwengelen, echter gaat het inderdaad om data. Dat maakt niet uit server-side of client-side, echter het uitrollen; de logistiek en (eventuele) impact hiervan is compleet verschillend.
Ik kan me dan goed voorstellen dat je de afweging maakt om je in dat proces te storten of mensen te adviseren even af te wachten en de functie een paar dagen uit te schakelen/handmatig te bedienen.
Als ondernemer zou ik je niet erg slim vinden als jij je telefoon overdag op de DnD stand zet dan is het nogal wiedes dat je dingen gaat missen. Daarnaast zijn er volgens mij maar weinig mensen die toch niet tussentijds even hun iPhone een keer aandrukken om te kijken of ze toch per ongeluk wat hebben gemist.
Daarboven op omhelst de functie ook nog een escape waarbij bepaalde contactpersonen altijd doorkomen en herhaaldelijke oproepen ook doorkomen. Ik kan me ook haast niet voorstellen dat veel mensen dat uitzetten. Met andere woorden; kritieke telefoontjes kun je haast niet missen.
Ik denk niet dat ze hier heel hard op worden afgerekend. Nogmaals; het is slordig, maar volgens mij niet kritiek en ik kan de afweging om gewoon af te wachten heel goed begrijpen.
Ik kan me dan goed voorstellen dat je de afweging maakt om je in dat proces te storten of mensen te adviseren even af te wachten en de functie een paar dagen uit te schakelen/handmatig te bedienen.
Als ondernemer zou ik je niet erg slim vinden als jij je telefoon overdag op de DnD stand zet
dan is het nogal wiedes dat je dingen gaat missen. Daarnaast zijn er volgens mij maar weinig mensen die toch niet tussentijds even hun iPhone een keer aandrukken om te kijken of ze toch per ongeluk wat hebben gemist.Daarboven op omhelst de functie ook nog een escape waarbij bepaalde contactpersonen altijd doorkomen en herhaaldelijke oproepen ook doorkomen. Ik kan me ook haast niet voorstellen dat veel mensen dat uitzetten. Met andere woorden; kritieke telefoontjes kun je haast niet missen.
Ik denk niet dat ze hier heel hard op worden afgerekend. Nogmaals; het is slordig, maar volgens mij niet kritiek en ik kan de afweging om gewoon af te wachten heel goed begrijpen.
Het punt is dat niet 'alles' stuk is, maar een functie waar mensen prima zonder mee kunnen. Neemt niet weg dat het erg slordig is, en natuurlijk niet had mogen gebeuren. Maar goed, dates en programmatuur zijn altijd een apart verhaal, zou inderdaad goed te maken kunnen hebben met week 1.
Als mijn software draaide op miljoenen devices over de hele wereld, dan zouden mijn klanten het niet accepteren als ik overhaast een fix de deur uit doe, die onmogelijk binnen een week uitvoerig getest kan zijn.Terugkomend op de reactie van Apple, mijn klanten zouden het niet accepteren als ik zou zeggen, wacht maar even een weekje dan doet alles het weer...
Als ze de bug hebben achterhaald, en hebben gezien dat het zichzelf oplost binnen een x aantal dagen, dan heeft het gewoon geen zin om een update te ontwikkelen, volledig te regressie-testen en uit te rollen, als die automatische oplossing toch eerder gaat zijn.
Overdrijven is ook een vak... Die bug is zo levensbedreigend en noodzakelijk dat jouw klanten geen 4 dagen zouden kunnen wachten? Hoelang denk je dat het duurt om een bugfix te maken, testen en distribueren aan miljoenen toestellen?Terugkomend op de reactie van Apple, mijn klanten zouden het niet accepteren als ik zou zeggen, wacht maar even een weekje dan doet alles het weer...
Bij mij gaat de functie juist niet meer automatisch aan. Vanzelf uit gaat wel weer prima.
Meerdere nieuwsberichten over zo'n minuscule bug waar niet veel mensen heel veel hinder van zullen ondervinden, je kunt het immers met twee drukken op het scherm handmatig uitschakelen, net zoals de vliegtuigmodus dus.
Net zoals die blogs die nu met z'n allen melden dat de nieuwe iPhone verschillende kleuren krijgt omdat 1 of andere zelfbenoemde analist dit beweert.
Net zoals die blogs die nu met z'n allen melden dat de nieuwe iPhone verschillende kleuren krijgt omdat 1 of andere zelfbenoemde analist dit beweert.
Vreemdgenoeg is het probleem hier nu op mijn 2 apparaten (iPhone 4S en iPad 3) ook verholpen.
Wat ik daarentegen wel weer vreemd vind is het gedrag van beide apparaten:
Wat ik daarentegen wel weer vreemd vind is het gedrag van beide apparaten:
- iPhone 4S met iOS 6.0.1 › Op 1 januari én 2 januari een “hangende maan”
- iPad3 met iOS 6.0.1› Alléén op 2 januari een “hangende maan”
Had het wel grappig gevonden als het na 21 December niet meer had gewerkt. 
Toch maar rare manier van communiceren: wacht tot volgende week, dan is het probleem automatisch weg. In plaats van te zeggen dat ze hard aan het werken zijn om de problemen op te lossen en dat we een bugfix binnen de dag zullen ontvangen. Maar zover zijn we precies niet op de mobiele markt.
Daarvoor is de bug niet zwaar genoeg, het gaat hier niet om een security issue en het kan nog steeds manueel uitgeschakeld worden. Ik neem dus aan dat er wel grotere problemen zijn en de fix gewoon in 1 van de volgende updates wel zal zitten zodat hij niet opnieuw voorkomt.
Ik neem aan dat ze er dus wel degelijk aan werken, maar gezien de korte periode waarin het problemen geeft er geen haast achter steken. Moest het een blijvende bug zijn zou men dat wel doen.
Ik neem aan dat ze er dus wel degelijk aan werken, maar gezien de korte periode waarin het problemen geeft er geen haast achter steken. Moest het een blijvende bug zijn zou men dat wel doen.
Ze zullen het onderzocht en gelokaliseerd hebben. Het lijkt er op dat ze daarbij hebben geconstateerd dat het uit zichzelf oplost op de 7e.
Zeer waarschijnlijk heeft het dus geen zin om een fix te ontwikkelen, te testen op de honderd meest voorkomende configuraties (je wil namelijk niet dat een fix nieuwe en mogelijk grotere problemen veroorzaakt), en dan over anderhalve week met een bugfix uit te komen nadat het zichzelf al heeft opgelost.
Het is volkomen logisch dat ze het zo oplossen. Het is hooguit raar dat ze niet bovenstaande uitleg (indien juist) communiceren.
Zeer waarschijnlijk heeft het dus geen zin om een fix te ontwikkelen, te testen op de honderd meest voorkomende configuraties (je wil namelijk niet dat een fix nieuwe en mogelijk grotere problemen veroorzaakt), en dan over anderhalve week met een bugfix uit te komen nadat het zichzelf al heeft opgelost.
Het is volkomen logisch dat ze het zo oplossen. Het is hooguit raar dat ze niet bovenstaande uitleg (indien juist) communiceren.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Asus Samsung Websites en communities Mobiele telefoons Laptops Sony Games Microsoft Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
