Time occasionally skips a second or two...
MoralCode opened this issue · comments
as can be seen here, every few seconds, the "metric time" skips a second.
this could cause things to become inaccurate, especially if the new analog clock isn't kept constantly in sync with the "metric" time.
this is even present in the updated version....
through logging of the milliseconds at each time capture, this seems like a pretty normal thing... every so often, the number of milliseconds "left over" after each recalculation gets bigger and bigger until it surpasses 864, the number of milliseconds in a metric second, causing it to skip.
well, after making the NSTimer interval equal to 864 ms (commit 4c9f6cb) i have noticed a large reduction in the frequency of the second-skipping...
I believe this is due to the NSTimer being a few fractions of a second late each time it calls the timer.
i will try to reduce this by a little bit more and see if that helps...
okay, so i have determined that i will need to get the app to run the update code every 864 milliseconds exactly. which is going to be such a mammoth task that i'm not even going to try.
However, i now have a more complete grasp on the problem and will attempt to explain it in detail:
When I scheduled the NSTimer to fire every 864 milliseconds, slight system-level events may have been causing it to fire a few milliseconds late. Those extra milliseconds add up and every so often, cause it to increment the seconds by two in order to keep the converted "metric time" accurate.
Additionally, when the NSTimer was set to fire every 864 ms, the aforementioned delay also somehow caused some seconds to appear to last slightly longer than others.
So, i am officially giving up on the time-skipping issue, however, i have found that by setting the NSTimer at a level where it, is only a fraction of the 864 millisecond cutoff (like 1/4 or 1/8 .etc) but is not fast enough to cause huge amounts of processor power to be used in running the app (something i experienced when the NSTimer was set to insanely low values like .0001), I can at least eliminate the issue of some seconds taking longer than others
Just had a thought... maybe this "bug" could turn into a feature by helping to sell MetricTime by including a statement like "Due to the fact that MetricTime is an entirely different timekeeping system, there are going to be inaccuracies during conversion, so we've implemented a feature in the app to intentionally skip a second in order to keep the app accurate."
this does not appear to be an issue with the latest version. closing
I suspect it still does this just less frequently. I think this is due to the very tiny inaccuracies when dividing Double data types since doubles aren't 100% precise.
May want to convert the MetricTime class to use Integer division instead (maybe�)
haha nope. I was neglecting to add the milliseconds in the time conversation function.