If you lie about the time zone, your iPhone will have its revenge
iPhone 6s and iPhone 6s Plus users are reporting that their phones are sometimes showing plenty of charge left even though their batteries are actually depleted, leaving some users stranded out of power. Apparently users who change their time (e.g., to gain unfair advantage in games like Candy Crush Saga) can confuse iOS 9.2 into not updating the battery percentage indicator. A similar problem can occur to users who set the time zone manually. One workaround is to reboot and revert to getting date and time from the network. Reference: Smith J. iPhone 6s battery bug leaves users longing for iOS 9.3. GottaBeMobile.com 2016-01-17. http://www.gottabemobile.com/2016/01/17/iphone-6s-battery-bug-leaves-users-l...
On Jan 17, 2016, at 11:14 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
iPhone 6s and iPhone 6s Plus users are reporting that their phones are sometimes showing plenty of charge left even though their batteries are actually depleted, leaving some users stranded out of power. Apparently users who change their time (e.g., to gain unfair advantage in games like Candy Crush Saga) can confuse iOS 9.2 into not updating the battery percentage indicator. A similar problem can occur to users who set the time zone manually. One workaround is to reboot and revert to getting date and time from the network.
Or, at least, to do so on iPhone 6s/6s Plus. This is a bit weird - I'd expect whatever checks the battery to be doing "check every second"-type checks, which *might* be confused if somebody actually did settimeofday() (General -> Date & Time -> turn off "Set Automatically" and then set the time manually), but which I wouldn't expect to be confused by removing /etc/timezone and re-linking it to another file (General -> Date & Time -> turn off "Set Automatically" and then set the time zone automatically). Then again, if it's only on the 6s models, maybe there's some new hardware in it that somehow has to deal with local time and that gets confused by time zone changes. (So what happens if whatever daemon is responsible for monitoring your location notices you've crossed a time zone boundary and changes the time zone *for* you? "Set Automatically" enables that.)
On 2016-01-18 00:42, Guy Harris wrote:
On Jan 17, 2016, at 11:14 PM, Paul Eggert wrote:
iPhone 6s and iPhone 6s Plus users are reporting that their phones are sometimes showing plenty of charge left even though their batteries are actually depleted, leaving some users stranded out of power. Apparently users who change their time (e.g., to gain unfair advantage in games like Candy Crush Saga) can confuse iOS 9.2 into not updating the battery percentage indicator. A similar problem can occur to users who set the time zone manually. One workaround is to reboot and revert to getting date and time from the network.
(So what happens if whatever daemon is responsible for monitoring your location notices you've crossed a time zone boundary and changes the time zone *for* you? "Set Automatically" enables that.)
It appears that also causes the problem, as would following their workaround instructions. Apple article at https://support.apple.com/en-us/HT205727 says: If your iPhone 6s or iPhone 6s Plus battery percentage doesn't update If you change the time on your iPhone 6s or iPhone 6s Plus manually or *change time zones when traveling*, you might notice that the battery percentage doesn't update. It recommends: 1. Restart your iPhone; 2. Change settings to Set Automatically. These instructions should probably be reversed as it changes the time zone, which causes the problem! -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
On 18/01/2016 6:42 pm, Guy Harris wrote:
I'd expect whatever checks the battery to be doing "check every second"-type checks
And I expect it to check the system uptime and not the wall clock time. Edwin
From: tz-bounces@iana.org [mailto:tz-bounces@iana.org] On Behalf Of Edwin Groothuis Sent: 19 January 2016 01:41 To: tz@iana.org Subject: Re: [tz] If you lie about the time zone, your iPhone will have its revenge
On 18/01/2016 6:42 pm, Guy Harris wrote:
I'd expect whatever checks the battery to be doing "check every second"-type checks
And I expect it to check the system uptime and not the wall clock time.
Or just loop, sleeping for duration d and not bothering with any time reference at all, for the calculation? Regards, Stephen Goudge ___________________________________________________________________________________________ This email has been scanned by Petards. The service is powered by Symantec MessageLabs Email AntiVirus.cloud ___________________________________________________________________________________________ This email has been sent from Petards Group plc or a member of the Petards group of companies. The information in this email is confidential and/or privileged. It is intended solely for the use of the addressee. Access to this email by anyone else is unauthorised. If you are not the intended recipient, any review, dissemination, disclosure, alteration, printing, circulation or transmission of this e-mail and/or any file or attachment transmitted with it, is prohibited and may be unlawful. Petards Group plc is registered in England & Wales. Company No. 2990100 ___________________________________________________________________________________________
On Jan 19, 2016, at 12:56 AM, Goudge, Stephen <stephen.goudge@petards.com> wrote:
From: tz-bounces@iana.org [mailto:tz-bounces@iana.org] On Behalf Of Edwin Groothuis Sent: 19 January 2016 01:41 To: tz@iana.org Subject: Re: [tz] If you lie about the time zone, your iPhone will have its revenge
On 18/01/2016 6:42 pm, Guy Harris wrote:
I'd expect whatever checks the battery to be doing "check every second"-type checks
And I expect it to check the system uptime and not the wall clock time.
Or just loop, sleeping for duration d and not bothering with any time reference at all, for the calculation?
Well, yes, that's what "check every second"-type checks *would* do (for d = 1 second). The point is that I'm not sure how something that doesn't actually change the system clock, such as moving from one time zone to another, would trigger this. But I'm also not sure why this would only be seen on the 6s models....
Guy Harris wrote:
The point is that I'm not sure how something that doesn't actually change the system clock, such as moving from one time zone to another, would trigger this.
I'm guessing that they have some code that monitors the battery's performance over long intervals, keeping data on charge and discharge rates and how they slowly change over time as the battery ages, only somebody accidentally used local rather than UTC timestamps, and the resulting anomalies if the offsets change get magnified by long lever arms (so to speak) to create potentially large aberrations in the displayed results.
On Jan 19, 2016, at 8:46 PM, Random832 <random832@fastmail.com> wrote:
Guy Harris <guy@alum.mit.edu> writes:
This is a bit weird - I'd expect whatever checks the battery to be doing "check every second"-type checks
Every second? That sounds like it would have an undesired influence the results of the checks.
Waking up once a second *iff* the display is on (if it's off, there's no point in updating the blacked-out battery charge level) and checking the battery probably won't run the battery down too much. If, however, the battery can itself interrupt the CPU when its charge level changes "significantly", that'd be even better. I don't know whether "smart batteries" can do that, but they might be able to.
Guy Harris <guy@alum.mit.edu> writes:
Waking up once a second *iff* the display is on (if it's off, there's no point in updating the blacked-out battery charge level)
Well, I'd read your "check every second" as implying logic that depends on checking it at fixed intervals, so whether the display is on or off. Otherwise you've got to store the timestamp of the last check (or of a longer-ago check, to get a smoother average) and subtract it from the current one... which this bug is apparently a result of such subtraction being done in local time.
Possible long-term hardware design fixes: * Real-time-clock circuitry with two counters: one that can be set by the user, and one that can't. The can't-be-user-set counter could return the age of the real-time-clock circuit itself, or TA1, or anything else--as long as differences in readings could reliably be used to measure elapsed time. * Real-time-clock circuitry that still has only one counter, where the single counter cannot be set by the user. In this case, it would need to be something such as TA1, set at manufacture (or, less likely, age-of-the-circuit-itself along with a stored value of what TA1 was at circuit birth). And a software approach: compute elapsed time by using values obtained from GPS rather than values obtained from internal hardware. Inapplicable when GPS is unavailable; introduces faulty GPS reception as a source of error in elapsed time computation. To relate the matter to time software: if you favor the "right" approach to leap seconds over the "POSIX" approach--don't monkey with time_t when leap seconds happen, just keep counting at one second per second--you might favor a non-monkeyable real-time-clock counter. @dashdashado On Wed, Jan 20, 2016 at 7:29 AM, Random832 <random832@fastmail.com> wrote:
Guy Harris <guy@alum.mit.edu> writes:
Waking up once a second *iff* the display is on (if it's off, there's no point in updating the blacked-out battery charge level)
Well, I'd read your "check every second" as implying logic that depends on checking it at fixed intervals, so whether the display is on or off. Otherwise you've got to store the timestamp of the last check (or of a longer-ago check, to get a smoother average) and subtract it from the current one... which this bug is apparently a result of such subtraction being done in local time.
On Wed, Jan 20, 2016 at 7:29 AM, Random832 <random832@fastmail.com <mailto:random832@fastmail.com>> wrote: Guy Harris <guy@alum.mit.edu <mailto:guy@alum.mit.edu>> writes: > Waking up once a second *iff* the display is on (if it's off, there's > no point in updating the blacked-out battery charge level) Well, I'd read your "check every second" as implying logic that depends on checking it at fixed intervals, so whether the display is on or off. Otherwise you've got to store the timestamp of the last check (or of a longer-ago check, to get a smoother average) and subtract it from the current one... which this bug is apparently a result of such subtraction being done in local time. On 2016-01-20 06:39, Arthur David Olson wrote: Possible long-term hardware design fixes: * Real-time-clock circuitry with two counters: one that can be set by the user, and one that can't. The can't-be-user-set counter could return the age of the real-time-clock circuit itself, or TA1, or anything else--as long as differences in readings could reliably be used to measure elapsed time. * Real-time-clock circuitry that still has only one counter, where the single counter cannot be set by the user. In this case, it would need to be something such as TA1, set at manufacture (or, less likely, age-of-the-circuit-itself along with a stored value of what TA1 was at circuit birth). And a software approach: compute elapsed time by using values obtained from GPS rather than values obtained from internal hardware. Inapplicable when GPS is unavailable; introduces faulty GPS reception as a source of error in elapsed time computation. To relate the matter to time software: if you favor the "right" approach to leap seconds over the "POSIX" approach--don't monkey with time_t when leap seconds happen, just keep counting at one second per second--you might favor a non-monkeyable real-time-clock counter.
Most small systems designed for low power run with tickless kernels and set a clock register to interrupt them when they need a wakeup, allowing the device to sleep and minimize power use. The kernel adjusts the time at wakeup, and may update battery use based on known sleep state power use. An inadvertent battery use adjustment may have been invoked during a time zone change instead of just changing the display offset. Winter is traditionally the time for patches to bug fixes after summer students leave in the fall ;^> Apps which keep a device from sleeping and burn thru battery life are either not allowed on the app store, or are downvoted by users whose batteries die quickly, and may be dropped by the app store, depending on the store's app vetting practices and policies. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
participants (8)
-
Arthur David Olson -
Brian Inglis -
Edwin Groothuis -
Goudge, Stephen -
Guy Harris -
Paul Eggert -
Random832 -
scs＠eskimo.com