"A press eager to expose Apple's fallibility"
I wouldn't say it's that so much as the fact that Apple articles make news editors so weak at the knees that I'm surprised we don't find out about it every time Steve Jobs farts.
US iPhone owners are again the last to know that spring has arrived, as their handsets decide to drop back by an hour instead of jumping forward as one might expect. Not that spring is here for everyone – the Scottish Highlands are still swathed in their traditional March snowfall – but in some parts of the world the clocks …
Do Gods fart? The queen doesn't so I'd be surprised if a God did.
If he they do then it would only be newsworthy if Jobs attempted to use his omnipotence to avoid a public decency charge in Malawi if they brought in the anti-farting law. Supposedly being a God and ever present everywhere his farts would be on a global scale much like his products. But then would the Malawis bow to the Jobsian deity.
Seriously, I have more faith in my old tiny nokia than these new fangled smartphones.
I suspect it doesn't matter what smart phone it is, for I believe for many things, simple done well trumps complex done well (which is arguably also less common).
I have an android for paying the jobs tax offends me, but still... as it stands I have to be up early in the morning, so my watch will be waking me up.
I used to berate MS for their piss-poor time keeping model (I mean, keeping local time in hardware and shifting that, famously leading to loops if old PCs were on over the DST change) but now its the iPhone's turn:
HOW F*UKING HARD IS IT?
UNIX had this sorted from the start by keeping the clock on UTC and changing the local time offset to suit. And we have ntp to keep clocks running more or less perfectly if you have a network link, as a smart phone with Internet access surly has?
So how come a UNIX-like phone is broked?
OK we may have the odd leap second to concern us as that can be unrepresentable in calender time (who's clock system can show 23:59:60 before going to 00:00:00?), but come on, not coping with DST is utterly crap.
This is an insanely fundamental thing to get wrong.
Especially when more and more systems use the tz database to keep track of all the regional DST differences.
It always annoys me when I have to use an application/system where you are asked to enter your current timezone by choosing a UTC offset rather than a TZ identifier eg: Europe/London.
Not being able to handle regional DST differences is inexcusable, that problem was solved years ago.
The "stable" of iDevices we use for testing all made the transition properly - and we have better than two dozen of them, all hardware models (iPhone, iPad, iPod touch from each major hardware rev) and all OS versions represented...
Evil Steve Jobs because, well, because I have to have so many devices and spend so much time testing stuff on them. And I'm most certainly NOT a fan.
One would have thought that the software behind such a simple function would have been perfected by now. I mean, why did Apple even have to change the code that does time?
Not only that, but after suffering once already from their customers and the press, they didn't even get it right on the second attempt..!
Most networks have a time service which presumably shifts when daylight savings kicks in. Perhaps the iPhone is automatically jumped to DST using it's own BSD based timezone info but it's misinterpreting the network's adjusted time on top of its own and screwing it all up. Could be a network issue or an Apple issue, or both. Or maybe it's just users with misconfigured phones.
I do have to wonder how a phone in its 4th generation could screw this up though. I assume Apple have the resources such as QA lab with a picocell where they could simulate timezone & DST changes in a reproduceable way.
Not on any phone I've ever seen anyway. You have to set the time yourself manually when you first get it, and again any time you take the battery out. Ordinary mobiles also don't track DST, and Apple's one only does because it has the knowledge programmed into it - incorrectly as it turns out - not because any kind of signal is sent from the network. (It might be getting NTP from an internet time server of course, but that is still nothing to do with the mobile phone provider's network.)
Depends on the network, but nearly every phone I've had on a variety of networks will reset the time for me, be it for Summer Time or time zone change when I've flown somewhere. I've had Motorolas, Nokias, and Apples (iPhone being the only "smartphone" I've owned; the others were standard phones with no data capabilities). They've all the option for manual intervention for time or to draw the time from the network. Once, my old Motorola failed to update on whatever network it grabbed at Copenhagen airport and, if not for the clocks on the wall, I'd have missed a flight. Granted, "my dozen phones" does not equal the set of all phones ever, but network time isn't a new or uncommon phone feature.
I was out of the UK last week, and as I do every year or so I experimented with setting my phone to "auto" rather than manually set time for the trip back. I've long been used to "auto" working outside the UK, pretty much everywhere.
For the first time ever, Vodafone UK succesfully changed the timezone when my phone re-registered after wandering off the plane. I was quite startled, I've been waiting for that to work for about ten years.
It's an iPhone4, but I don't expect that makes much difference.
It's the whole time-space continuum warping where it comes into contact with the Jobsian reality distortion field. Apple will, within the week, release a statement denying the whole thing in general terms, but point people towards a page where they'll explain how the mortal universe should properly hold Jobsian trinkets.
Any reasonable system should run it's internal clock on UTC all the time, regardless of timezone and whether DST is in effect, and just alter the presentation of local time according to it's location, so 'adjusting' the clock should never be required. You should never have have the hardware clock changed on a correctly configured UNIX or Linux system, except to take into account leap-seconds or clock-drift.
This has always bugged the hell out of me when using a dual boot Linux/other-OS PC. Linux worked just swell changing the presented time according to DST, and then you boot your other operating system that ALTERS THE FREAKING UNDERLYING CLOCK!!!
When I put Ubuntu Lucid Lynx (10.04) on my Thinkpad last year, I was expecting this, but found that some misguided bright spark has added code to Linux (probably somewhere else other than Canonical) that actually expects the underlying clock to be changed incorrectly by the other-OS, and then 'breaks' the working tradditional UNIX/Linux time support to take this incorrect clock setting into account. Talk about working around someone else's errors.
Good for all the people who want it to just work and regularly boot both OS's, bad for anybody who actually understands what should be going on. Drove me nuts for an hour or two.
Hang on a sec. Back to iOS. Isn't it a UNIX/BSD derived OS?......
The Linux kernel code to assume that the hardware clock is in local time has been in there for at least as long as I've been using Linux - I built my first Linux kernel in 1995, a custom version of 1.3.5. There's a configuration option in the kernel build to use UTC or local time, and it looks like Canonical enabled local time so that it is easier for people dual-booting to Windows.
I'm a UNIX person through and through, and the first time I looked at this was in about 1987, with SVR2, which had code for DST, but had the cut-over dates to and from DST hard-coded in libc.
There is a configuration option that allows you to vary whether the clock is localtime or UTC without having to re-compile the kernel (a bit heavy handed in this day and age). It is based around setting UTC=yes early in the boot process (in /etc/default/rcS). The initial setting for a new install is supposed to be queried during the install process. I suppose I may have set it wrong, but I don't think that I would have made such an error, bearing in mind I was aware of the problem. Maybe I'll install again from the original media I had to see whether there was a flaw in the install process.
In my (biased, I admit) view, it's wrong to run a system on localtime, but I am in the UK, and winter time is the same as UTC (well, GMT anyway), so I have never had to worry about anything other than the Daylight Saving Time change. I guess that other locations have it harder.
Why call it daylight saving time? There's more daylight about in the summer so why does it need saving.
What we really mean is people like to get up at the same time of day every day of the year so lets move the clock about so people can enjoy more of that daylight. Which is fair enough, but everybody who is in support of extending daylight saving always seems to use farmers as the excuse. Well 'scuse me, but don't farmers get up with the sun anyway so they don't really care about daylight saving, they don't work 9-5. The probably don't own iPhone's either.
Agreed, how the fuck hard CAN it be ? Actually, that's an entirely rhetorical question, I've been writing software for more than 20 years now, so I know the answer, which is "slightly harder than you initially imagine it to be, but not by very much"
Besides which, this is a solved problem, not only in general but very specifically in the very OS from which iOS is derived, FFS.
At the point at which it was first discovered that there were stupid enough bugs in the timekeeping code that it looked like some dimwitted google SoC intern had been allowed to write it, it should have been ripped out and debugged or rewritten until it passed an incredibly strict QA procedure, and whoever had written the initial version should have been out of a job.
And yet apparently the SoC intern, rather than being driven out of town with a pointy stick has been hired and is now cak handedly chucking shitty work arounds into that code one trouble ticket at a time rather than understanding that it is fundamentally borken.
Unlike some of the vi loving Luddites in the above comments, I personally do happen to believe that the least thing my smartphone should be able to do is to tell me what bastard time it is, the fact that I am still unable to trust it to do so, several major versions after the first time this happened says some very, very, bad things about the iOS development process.
Then again, this will come as no surprise to anyone with exposure to radar (Apple's bug reporting system, not the radio kind)
Ah good, a bit more ammo to bait my iphone owning friends with... Good old Apple, knew you wouldn't let me down.
Seriously though this is getting a bit beyond a joke, even M$ have managed to get windows to do this correctly, so we all know that means it can't be that hard!
As has been observed above, Apple have fallen for the all too common habit of clearing bugs from the fault list as fast as possible to make figures look good. Testing them would make the clearing task slower, so testing goes out the window... and the bug comes back a bit further down the list - that's okay though, as nobody seems to link the new bug to a previous cleared report and point out that a clock fault has existed for several years.
Pretending it's an hour later than it really is for half the year is a really lousy way of dealing with the fact that it gets light earlier and it gets dark later in Summer.
09:00 to 17:00 was chosen as the working day so that a man (because it would be a man in those days) would have enough daylight to wash and shave before walking to work each morning, even in the depths of winter.
We should keep UTC all year around, so that midday falls as near as possible to 12:00, and just open for business from 09:00 to 17:00 in Winter, and 08:00 to 16:00 in Summer.
A: The Phones draw their time settings from the NETWORK and,
B: Every iPhone I know set fine. Our phones set fine.
You want to point fingers, point them at AT&T and their overloaded, unreliable, obsolete network.
Notice this says specifically AMERICAN iPhone users? Methinks the time updates from AT&T are to blame.
Some of you guys are so determined to grind on Apple you would blame iPhones for cold sores. Get over yourselves.
Biting the hand that feeds IT © 1998–2019