Feeds

back to article 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 to …

COMMENTS

This topic is closed for new posts.

Page:

Trollface

"trouncing Venus and Serena Williams"

Shirley most iFans are always of the opinion that they're better than everyone else regardless of being Asleep/ Awake?

8
3
Headmaster

Re: "trouncing Venus and Serena Williams"

Don't call me Surely!

1
0
Anonymous Coward

So

That's why I keep missing calls and losing business.!

Any No Win No Fee people reading this, if so give me a call.....

2
0
Joke

Re: So

Remember to switch the DND off, or you'll miss them as well......

0
0

Re: So

Yep. Went back to work at 9am Wednesday, expecting lots of phone calls. Wife rang at 10am, and after I got off the phone I noticed 8 missed calls and only 4 left a message. By 11am I had realised the problem but possibly lost some business.

Thanks a bloody bunch Apple.

0
0
Trollface

Re: "Don't call me Surely!"

OK, you're Surly...

0
0
Bronze badge

Close...

:It Just Borks!"

11
1
FAIL

Not again!

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.

8
0

Re: Not again!

Time measurement may not have changed but the turn over of cheap young developers who have not seen this bug before is quite frequent.

If you are experienced enough to remember a time based bug then you are likely too expensive.

17
0
Bronze badge

Re: Not again!

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]

19
3

This post has been deleted by its author

Anonymous Coward

Re: Not again!

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

6
0
Anonymous Coward

Re: Not again!

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

1
0
Bronze badge
FAIL

Re: Not again!

To me

cheap young developers

is code for hiring a H-1B

1
0
Anonymous Coward

Re: Not again!

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

0
0
Silver badge

Re: Not again!

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.

1
0

Re: Not again!

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

0
0
Trollface

Re: Not again!

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

0
0

iPad Calendar crashes if you open March month view...

...when there is an event spanning the March/April boundary (or something like that). There does seem to be a date related blind spot in Apple's software development.

4
0
Bronze badge

Re: iPad Calendar crashes if you open March month view...

You're scheduling wrong.

7
0
Bronze badge

Re: iPad Calendar crashes ... event spanning the March/April boundary

I guess you have seen Apple's solution to the infamous April Fool's Day bug - just ignore it.

0
0
Silver badge
Happy

So who resigned this time?

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?

7
1

Explanation wanted

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.

1
0

Re: Explanation wanted

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.

0
0
Joke

Re: Explanation wanted

Well this year is 2013, which in hex is 7DD. Perhaps the "DD" part of that distracted the coders and the bug slipped through?

3
0

Re: Explanation wanted

The scheduling feature just gives you a time you want Do Not Disturb to come on, and a time you want it off. There's no concept of individual days at all. Which is why it seems so odd.

1
0
Anonymous Coward

Re: Explanation wanted

Maybe it's something odd with week 1 of 2013 starting on the last day of 2012... so maybe Apple thinks it's week 53 of 2012

0
0
Bronze badge
Joke

Re: Distracted coder

If I am going to be distracted, then it should be by at least a 38DD!

0
0
Bronze badge

Re: Explanation wanted

The world end a few weeks back, so they didn't think to check an impossible date.

0
0
FAIL

ISO weeks

Seems related to formatting of ISO dates. It's 2012 til the end of the 6th using the ISO date format.

1
0

Re: ISO weeks

Not an iOS programmer but I think this has been caused by using 'YYYY' instead of 'yyyy' as the year formatter.

1
0
Meh

*Time* for change ?

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

5
0
Silver badge

Re: *Time* for change ?

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

0
0
Anonymous Coward

Gotta get that maps dig in, right?

Heaven forbid El Reg post an iOS story without taking time to slag off the maps app.

4
7
Silver badge
Trollface

Re: Gotta get that maps dig in, right?

El Reg aka Trollfests'R'Us, innit?

1
1
Mushroom

Re: Gotta get that maps dig in, right?

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.

0
0
Anonymous Coward

Time is the Simplest Thing

Updating a web site just before midnight on New Year's Eve - the new host timestamps were reported in the FTP directory listing as 1/1/2012. The host was on CET and the XP CuteFTP8 client was on GMT.

0
0
Bronze badge
Happy

Re: Time is the Simplest Thing

Ooo, I do hope that was a reference to one of my fave SF books by Clifford D Simak...?

0
0
Anonymous Coward

Re: Time is the Simplest Thing

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

0
0
Anonymous Coward

"......Apple's a cock-up, it is another bit of egg tossed onto the face of Apple's cherished, carefully cultivated "It Just Works" reputation."

Ha ha. Think differently, think "what a huge pile 'o shite".

0
5
Silver badge
Happy

On the 12th. day of Christmas my true love gave to me....

An Ubuntu phone in a pear tree.

at 1am Jan 8 -c apt-get install get_iplayer && notify-send "Nice pears!"

1
0
Anonymous Coward

Oddest bit

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.

0
0

Re: Oddest bit

OSX and iOS are BSD variants, but they have their own date time library NSDate (The NS prefix comes from NEXTSTep)

I don't think there is a problem with the library (otherwise this would have cropped up a long time ago), more a problem with how it's been used. PEBKAP basically

0
0

Re: Oddest bit

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.

0
0

Apple - they get viruses, they break and they ship with bad code, not to mention the company itself has become the most hated on earth (unless you're part of the Jobsian religion). Essentially, they've replaced Microsoft.

0
1
Silver badge
WTF?

"not to mention the company itself has become the most hated on earth"

You mean "by you"? It's entirely possible to neither love nor hate Apple you know. Google "most hated companies" if you want a real list.

0
0
Happy

Profile scheduler on android market works. Another reason to switch?

https://play.google.com/store/apps/details?id=com.wetpalm.ProfileScheduler&feature=search_result#?t=W251bGwsMSwyLDEsImNvbS53ZXRwYWxtLlByb2ZpbGVTY2hlZHVsZXIiXQ..

0
0
Unhappy

Does anybody, really, do time correctly?

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.

0
0
Anonymous Coward

Re: Does anybody, really, do time correctly?

I remember a youngster designing a 24x7 CCTV library system. They were proposing using local time for logging. They hadn't considered that Daylight Saving would produce a duplicated hour when the clocks went back.

0
0
Bronze badge

Re: Does anybody, really, do time correctly?

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

  • UTC (plus time zone offset and daylight savings time) is what we use day to day and, importantly, is what your PC is very nearly set to by NTP. UTC is 'legal time' almost everywhere in the world. That normally means that time stamped data, video, audio, etc. will be accepted by a court only if you can show that the time stamps are accurately synchronised to UTC.
  • TAI, Temps Atomique International is what all the atomic clocks round the world use. It is authoritative in that all other time-scales, including UTC, are derived from it. It has no leap seconds, no DST, no leap years. That's good for calculations.
  • TCG, TCB, GCRS, which are definitely much more astronomical...

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

3
0

Page:

This topic is closed for new posts.