[tz] If you lie about the time zone, your iPhone will have its revenge

[Arthur David Olson]

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 at fastmail.com> wrote:

> Guy Harris <guy at 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20160120/7761f88b/attachment.html>