Quote:
Originally Posted by
jkmassel 
Three pages of people complaining, but on an Apple forum, nobody remembers that this is a fairly complicated problem?
I've personally written event management software, and let me tell you - time zone management and recurring events are nontrivial things to figure out. That's why there are many libraries out there that try to do that for you, but sometimes even those don't work (although traditionally that's in esoteric situations, most places don't mess with their timezones).
This is a tough problem, that can be ridiculously hard to track down. Of course, I demand perfection from apple as much as any bloke, but this truly is a difficult problem, and as it turns out, their solution breaks. Strangely, it doesn't seem to use core libraries already built into the system (for iCal) to handle this. I can't imagine why not, that seems to work fairly smoothly.
Programming IS certainly complicated and for as long as software is written it will contain bugs whether written by Apple, Microsoft, IBM or anyone. Some bugs, like "If I draw a new object, move it 20 pixels, then shade it green, switch the app to inactive, the click back in the document, give the object a drop shadow and then duplicate it, then sometimes the app crashes may be impossible to replicate! The causes of some bugs are easy to understand (divide by 0 for example) and some can be very, very difficult to fix. The thing about this bug though is that:
*) The number of days in any year is known precisely as are the days in a month.
*) All leap years and their effects are known in advance
*) Times for the beginning and ending of Daylight Savings Times are published for all countries well in advance (or there would be no chance at all of getting this right at all!)
*) The choices in the Alarm Clock app are decided by Apple, namely: you can set a one off alarm or a repeating pattern with a finite number of options.
Therefore given a single TZ, only certain things need testing and they are all knowable in advance. Considering the complexity of software that Apple has written (Core Animation, Spotlight, Core Video, Aperture, Final Cut, etc. etc. etc.) this should be trivial and saying that it is "a truly difficult problem" is failing to address what's going on. As I said in a previous post, our software for the BBC had to handle all this kind of thing, including stopping people setting a program to broadcast at, say 1:30am in a country where the DST came into force and meant that 1:30am "happened twice" after the clocks went back. It also had to handle the same situation where 1:30am would not exist when the clocks change the other way and the clocks jumps from 1am to 2am. Again, all this is known and mathematically predictable years in advance and can and should be tested for.
If you read Apple's Framework documentation for NSDate, NSTimeZone and NSCalendar you will see the depth of thinking about dates that has gone into it by Apple and others so it's not as though they are not aware of the complexity in coding for date calculations which makes something as simple as "When I cross into a new year, this bug happens" such a surprising error.
As for "get over it" or not, well, how important this bug is to each of us depends on how we use Apple's mobile devices. If you never use the Alarm Clock app it will be irrelevant, if you rely on it for critical events then it will be significant and just calling people "stupid" for relying on Apple's software is hardly the point.
I don't expect perfection from any software company, just the very best they can do, but falling over on something of this nature is rather elementary for a company employing some of the finest software engineers on the Planet.
\
YES MY ALARMCLOCK HAS WORKED FOR SEVERAL YEARS WITHOUT THIS STUPIDITY!!!
