<div dir="ltr"><div><div><div><div><div>Possible long-term hardware design fixes:<br><br></div>* 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.<br><br></div>* 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).<br><br></div>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.<br><br></div>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.<br><br></div> @dashdashado<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 20, 2016 at 7:29 AM, Random832 <span dir="ltr"><<a href="mailto:random832@fastmail.com" target="_blank">random832@fastmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Guy Harris <<a href="mailto:guy@alum.mit.edu">guy@alum.mit.edu</a>> writes:<br>
> Waking up once a second *iff* the display is on (if it's off, there's<br>
> no point in updating the blacked-out battery charge level)<br>
<br>
</span>Well, I'd read your "check every second" as implying logic that depends<br>
on checking it at fixed intervals, so whether the display is on or<br>
off. Otherwise you've got to store the timestamp of the last check (or<br>
of a longer-ago check, to get a smoother average) and subtract it from<br>
the current one... which this bug is apparently a result of such<br>
subtraction being done in local time.<br>
<br>
</blockquote></div><br></div>