iPhone 'Do Not Disturb' bug to self-destruct on Monday Users of Apple's iPhone will have to wait until Monday for its latest bug to fix itself. On January 1, iOS 6's Do Not Disturb feature, which allows users to choose time periods during which they don't want to receive calls and to limit calls that do come through to members of selected groups, decided that it no longer wanted …
I can understand many bugs but I cannot understand leap year bugs (I'm looking at you, Microsoft) nor these date/time bugs that pop up on a regular basis in iOS. The way we account for time (except for DLST) hasn't changed in many, many years. I am not sure why Apple apps have trouble watching the clock.
Indeed, and time bugs generally don't show up under the oh-so-brief testing that many programmers are prepared to conduct. Time bugs tend to be caught only whenever they eventually occur, or in a properly thorough code review (a rare thing these days I suspect).
I speculate that the age of web development is to blame. It seems to have inspired a results now, now now culture, forget about quality (JavaScript? Really???). Bugs are accepted because a website can be fixed and the distribution of that is accomplished immediately with nothing more than a page refresh. Worse, many web rendering engines go to quite a lot of effort to automatically cope with common HTML errors: surely that's a crazy place to be?!
That culture is intruding into the more traditional worlds of software and OS development, which is *not* good! Got a stupid, oh-no-not-again time bug in an app built into an OS? Who cares - fix it at the next update.
One of Apple's biggest successes is to re-educate end users into accepting technically worse products (can't tell the time, can't really make a phone call, terrible battery life, inefficient use of bandwidth, etc), because at the end of the day a lot of punters are more interested in the style of the thing.
Unfortunately the other manufacturers (Google, MS) have seen Apple's huge profit margins and have realised that there's no point them trying to achieve a high technical quality either. That's got to be a backward step :-( Android is littered with problems (and Google have no effective update mechanism for the end user either). WinPhone 8 has/had a random reset problem (fixed now?). How did that ever pass pre-launch quality control?
[jet lagged and grumpy]
How did that ever pass pre-launch quality control?
Quality Control in software have the same purpose as Risk Control in banking, its mostly ceremonial (and if it actually does it's job, it will be slagged for "hurting profits" and "disrupting the schedule" after which cutbacks will be made).
Just saved an Excel spreadsheet with Swedish characters in it as "CSV", load it back up and ..... Unicode Bugs!!
This post has been deleted by its author
"Time measurement may not have changed but the turn over of cheap young developers who have not seen this bug before is quite frequent."
Alternatively a new programmer has said "That calculation is overly complicated - it's easier than that. There - fixed it!. It's so obvious it doesn't even need regression testing".
Alternatively a new programmer has said "That calculation is overly complicated - it's easier than that. There - fixed it!. It's so obvious it doesn't even need regression testing".
IMHO, that would be the original programmer's fault for omitting the explanatory comment that should have accompanied the non-obvious calculation.
"If you are experienced enough to remember a time based bug then you are likely too expensive."
My favourite one recently was in a bank's PnL tool that calculated the accumulative portfolio totals.
Since markets are only open on working days, the developer had been clever enough to allow the user to maintain a list of holidays (even though the bank has a central golden source for such things). Unfortunately, the tool was always run from London so the holiday dates were only for London.
I happened to be working there as they were ramping up the scope to include international portfolios. It worked fine for weeks until there were some Singapore trades included while it was a bank holiday over there but not here. Since the holiday was a Friday it wasn't noticed until late Monday.
Cue much scratching of heads as to why some portfolios (containing a mix of SGD and GBP trades were slightly out).
While building a permanent solution, I also found some interesting hard-codings, like all years are 365 days. I was slightly tempted to leave them in for someone else to find in a few years ;) (I didn't)
"Unfortunately, the tool was always run from London so the holiday dates were only for London."
Even in UK companies it can get tricky when analysing the "working week" activities of local offices. Not only are there different Bank Holidays for the different countries - but there used to be very local branch closures on apparently arbitrary days like "last Tuesday in every month".
"Since markets are only open on working days"
Yes, and what, apart from holidays, hurricanes, and other disruptions is the other major obstacle to getting this right when operating on a global basis?
Weekends.
The trading week in Israel is Sun-Thu, and the weekend is Fri/Sat, so shares and other assets can trade in Tel Aviv on a Sunday, but not on a Friday. Somewhere else - it's been a few years, so I don't remember where - has Saturdays as a trading day.
Forex is even worse, as it is one of the few things that trades pretty much everywhere and is the same asset everywhere it trades, and so can (on the shared trading days) trade on a non-stop basis, changing only the location of the trades.
Is there some "head of scheduling management" top boss who refused to sign a letter of apology?
Will there be a 1 line "sorry" sentence in the British newspapers in 1pt scribble, surrounded by 96pt "Apple are great and can take this piss out of the British legal system all they want ner ner-ne-ner ner" text?
Can any of El Reg's reader boffins come up with a good explanation as to how this could happen in the software? Some bugs are obvious once they crop up but this one is odd, seems to be just the first week of the year?
I've run into time and calendar based bugs a number of times but can't think what could cause this behaviour.
I can't explain it for sure (not source code) but:
The explanation that the bug will fix itself on 7th of Jan, make me think the subtract one week or more likely set the day of the week to Sat/Sun of the Calendar (I presume NSCalendar). Then do not update the year, so the universal time returned is in 2012.
The assumption will have more merit, if there is setting for the weekends. I have no clue how the application looks/works, this is judging from the screenshot of the UI and the reported bug info.
It still makes me giggle that Apple are incapable of getting something as important and (currently) predictable as time right. I remember Nokia introducing scheduled profiles years ago and they didn't suffer from any of these issues.. you know why ? they actually tested their code. Back then updating phones software was not as easy/commonplace as it is today.
In fact, it's not just Apple.. Most software manufacturers don't care about Quality control anymore because it's all to easy to send an update out. Just look at the number of Playstation games that have had issues. You buy the game off the shelf then you have to wait an hour to play it while you download a forced update of the game because it's already broken before it went on sale!
Obviously bugs creep in - some of this code is highly complex and there are some scenarios that the writers will just not have thought of, but some stuff "should just work". But then look at Apple, when did they last release a major product that *didn't* have a problem..
"I remember Nokia introducing scheduled profiles years ago and they didn't suffer from any of these issues.. you know why ? they actually tested their code. Back then updating phones software was not as easy/commonplace as it is today"
Granted, it's a stupid bug on Apple's part, but comparing it to a Nokia profile schedule of the 90s (when I recall it on my 3310) isn't particularly fair. Yes they probably did have better test coverage, but I suspect it was a much smaller code path on of the old Nokia OS and so a lot easier to achieve that coverage compared with a smartphone. The demand for features wasn't as great either.
But yes, old Nokias had bugs too, even the aforementioned 3310 (had trouble operating when "no service" was displayed and rebooted).
Yeah. I have both Google and Apple's maps and Apple's works better and is more accurate in my area so I think the cock up about maps is damn silly. And the truth is, tackling maps is a difficult problem to begin with so errors (of which I've seen many on Google's maps) are understandable.
The date bug though, that's elementary stuff. I think it's worse.
"Ooo, I do hope that was a reference to one of my fave SF books by Clifford D Simak...?"
Indeed it was - probably last read 30 years ago. The title just popped into my head - and I had to check my memory of it. It's the only Simak novel that has survived the purges of my sci-fi section - the "grass" and "talking dogs" ones haven't. Time to re-read it as I've forgotten the plot. The synopsis suggests it is an appropriate tag for something apparently travelling back in time.
I believe that IOS is supposed to be a relative of OS X. OS X, being a BSD variant, has got well tried and tested date/time libraries. So were these ignored or rewritten very badly to make them smaller for a mobile 'phone? Or is IOS in fact a completely rewritten operating system, with no relationship to OS X? (OS X seems good, very solid, just like the original BSD and much more so than Linux.)
I agree with the comment about inexperienced, but cheap, programmers and desingers. You can employ more for less and get better quality bugs, more quickly, while insisting the retirement age must rise as it is cheaper to pay unemployment than pensions.(for the employer).
As for testing and code review - try that where I have to work. I recall that, in "The Mythical Man Month", Brooks wrote that testing should occupy at least half of the project time. But it is always the first part to be cut.
Grumpy and increasingly aged.
This is the thing.
It seems that far to many programmers don't want to use available APIs or libraries when needing to do something very standard. All major operating systems come with date and time libraries, and major programming languages even come with standard APIs to do this sort of thing (or are an easily available well known library if you're going low level). There should be no need for most programmers to ever have to implement anything to do with dates or times, standard TCP/IP communications, file reads and writes, encryption and hashing etc. For dates and times if you can't explain leap years and leap seconds (yup, leap seconds are a thing on most POSIX systems by default, but not default Windows), and have a defensible argument for if you are going to implement support for them, you shouldn't be trying to do it, because you don't understand it.
Pretty poor of Apple. Without wishing to defend them, time is really hard to do right.
Sure there are cases where the programmer makes basic errors (for example, next year = getCurrentDate() + 365...you know the types of dodgy assumption I mean).
But thinking on it some more, does a library that actually copes with how time is really used in the software world even exist? I was reading through this link about falsehoods that programmers believe about time (http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time) and I can't think of a single library that could cope with even half of these.
Time is hard. Really hard.
@KingZongo,
Yes, the astronomers do do time correctly. After all, they more or less define what 'time' is anyway. You might be interested in taking a look at this and particularly this manual (PDF) from the International Astronomical Union's Standards of Fundamental Astronomy library.
What it does
Essentially that C library gives you a set of routines to convert between different time scales like UTC, TAI and many others.
Using this library gives you the option of converting time stamps into TIA for storage / calculations, etc, and back to UTC for display purposes. It deals with leap seconds too, so relative time calculations are completely accurate.
Minor Drawback
The only drawback that I see is that if you truly care about leap seconds you have to download a new version of the library and recompile your code every time the world agrees on a new leap second. This is at most twice a year (end of June, end of December) with several month's notice, but quite often a few years goes past without one.
NTP, POSIX
It's a great shame that NTP and POSIX don't handle leap seconds perfectly. In NTP time nearly stops for a second; if you read NTP during a leap second you get 23:59:59, plus 1 extra nanosecond for each time you read it. That means that two time stamps taken nearly one second apart during a leap second are numerically only 1 nanosecond apart.
In POSIX (UNIX, Linux) time is put back one second at the end of the leap second, so you get another 00:00:00... Two timestamps taken at 23:59:60.9 UTC and 00:00:00.1 UTC will, in POSIX, apparently be in reverse time order (00:00:00.9 and 00:00:00.1). Imagine if that were used to check a nuclear reactor was running well...
If you have applications where time calculations must be accurate then you have to be very careful around leap second time if you just use the bog standard OS libraries.
Some people have fudged NTP to make leap seconds work a bit better. Google, on learning that a leap second is coming up, will adjust their time reference frequency a little bit. When midnight Dec 31st comes by they've drifted by the requisite leap already, and they then set the time reference frequency back to normal. It means that for a few months their 'time of day' is increasingly off, building up to a whole second by 23:59:59 31/12 at which point UTC changes as the leap second takes effect.
My own view is that it would be far simpler if the clocks inside PCs were maintained at TAI (perhaps by something like NTP). OSes could then provide built in support for something like the SOFA library so that programs can store and calculate using TAI but display and input in UTC. That would make it far, far easier for programmers to completely avoid time bugs. I know that there are some initiatives along these lines, but progress is slow AFAIK.
Links
http://www.iausofa.org/current_C.html#Downloads
http://www.iausofa.org/2012_0301_C/sofa/sofa_ts_c.pdf
http://www.eecis.udel.edu/~mills/leap.html
I would second your suggestion!
Adapt NTP to offer TIA along with some ways(s) of getting leap second and UT1-UTC information (either in NTP packet if small enough, or several redundant web sites with it in a standard machine-readable ASCII format, etc), then practically everything you ever need to do time-wise is sorted! No leap second problems, time differences easily computed in either civil (UTC) or real (TIA) cases, etc.
I've done time programming in the bad old 6502 assembler days. There are plenty of gotchas, but no excuse for not testing boundaries. All you have to do is set the thing just before such events and watch what happens. Even before the interwebbies there were acres of documents covering all sorts of calendars and variants. Year ends, leap years, alternate calendars... they are just tedious, not difficult.
Oh, and it makes no difference whether you are using library routines or rolling your own. Always test!
£600 phone that doesn't ring when get a call .. £600 quid well spent, I could get a crappy Nokia from those cheap "unblock your phone" and get a sim for quid here type of cheapo shops, and at least it would f**king ring!!
I've turned off my voicemail and turned the phone off, might as well get another week of rest :-P
I know what I won't be buying when I next upgrade, someone please make a youtube joke video about "can I upgrade my phone?" (you might need to be in the UK to get that - P 4 U, if you need a hint) and they offer you a Nokia 1 Brick as an upgrade (which probably can't handle SMS messages and has crappy TeleText graphics, LOL)
Steve Jobs must be turning in his grave, if only he could get the text message about the bug!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
