It might be like this:
* The self-test the iPhone performs to gauge battery life might be expensive in some respect -- e.g., it might drain the battery a little.
* As an optimization, the measured life is cached after being read, along with the time the actual test was performed.
* When the battery display is to be updated it checks the current time vs. the time the battery was last actually tested. If not enough time has passed, the cached life is returned rather than performing the expensive test.
This could break down by changing the time back after a test. E,g.:
1. Battery is actually tested at 6:00am 1/1/2016. The result is 80%. The result and current time is recorded.
2. User sets time back to 1/1/2015 for whatever reason.
3. iOS decides to update the display and reads the battery life
4. The time since last actual measurement is negative one year: the cached value of 80% is retuned.
... battery runs down
... steps 3 and 4 repeat periodically, but since the clock is set back so far, the cached result continues to be used rather than performing an extra check.
The solution is to not use clock time to cache the value, but rather an internal "tick" that keeps counting up regardless of the clock.
I don't have sympathy for people changing the clock to avoid trial restrictions, but this may affect travelers or anyone during DST changes. (They might be using GMT clock time, in which case changing time zone would not cause a problem.)
[doublepost=1453059717][/doublepost]
As a software developer, I can assure everyone that you are full of it.
Software -- whether app, OS, or driver -- determines how efficiently every resource on the device is used and that directly impacts battery life. And so does the capacity of the battery, of course.
[doublepost=1453059872][/doublepost]
OP didn't change the time, so it's not the same issue and therefore may not be a software issue.
