Calculating number of seconds between two points in time, in Cocoa, even when system clock has changed mid-way

Question

I'm writing a Cocoa OS X (Leopard 10.5+) end-user program that's using timestamps to calculate statistics for how long something is being displayed on the screen. Time is calculated periodically while the program runs using a repeating NSTimer. [NSDate date] is used to capture timestamps, Start and Finish. Calculating the difference between the two dates in seconds is trivial.

A problem occurs if an end-user or ntp changes the system clock. [NSDate date] relies on the system clock, so if it's changed, the Finish variable will be skewed relative to the Start, messing up the time calculation significantly. My question:

1. How can I accurately calculate the time between Start and Finish, in seconds, even when the system clock is changed mid-way?

I'm thinking that I need a non-changing reference point in time so I can calculate how many seconds has passed since then. For example, system uptime. 10.6 has - (NSTimeInterval)systemUptime, part of NSProcessInfo, which provides system uptime. However, this won't work as my app must work in 10.5.

I've tried creating a time counter using NSTimer, but this isn't accurate. NSTimer has several different run modes and can only run one at a time. NSTimer (by default) is put into the default run mode. If a user starts manipulating the UI for a long enough time, this will enter NSEventTrackingRunLoopMode and skip over the default run mode, which can lead to NSTimer firings being skipped, making it an inaccurate way of counting seconds.

I've also thought about creating a separate thread (NSRunLoop) to run a NSTimer second-counter, keeping it away from UI interactions. But I'm very new to multi-threading and I'd like to stay away from that if possible. Also, I'm not sure if this would work accurately in the event the CPU gets pegged by another application (Photoshop rendering a large image, etc...), causing my NSRunLoop to be put on hold for long enough to mess up its NSTimer.

I appreciate any help. :)

Twit

10.6 also has NSSystemClockDidChangeNotification which would certainly be handy here. – Hamamatsu

Answer 1

I figured out a way to do this using the UpTime() C function, provided in <CoreServices/CoreServices.h>. This returns Absolute Time (CPU-specific), which can easily be converted into Duration Time (milliseconds, or nanoseconds). Details here: http://www.meandmark.com/timingpart1.html (look under part 3 for UpTime)

I couldn't get mach_absolute_time() to work properly, likely due to my lack of knowledge on it, and not being able to find much documentation on the web about it. It appears to grab the same time as UpTime(), but converting it into a double left me dumbfounded.

[[NSApp currentEvent] timestamp] did work, but only if the application was receiving NSEvents. If the application went into the foreground, it wouldn't receive events, and [[NSApp currentEvent] timestamp] would simply continue to return the same old timestamp again and again in an NSTimer firing method, until the end-user decided to interact with the app again.

Thanks for all your help Marc and Mike! You both definitely sent me in the right direction leading to the answer. :)

Twit

Answer 2

Depending on what's driving this code, you have 2 choices:

• For absolute precision, use mach_absolute_time(). It will give the time interval exactly between the points at which you called the function.
• But in a GUI app, this is often actually undesirable. Instead, you want the time difference between the events that started and finished your duration. If so, compare [[NSApp currentEvent] timestamp]

Gherlein

Answer 3

Okay so this is a long shot, but you could try implementing something sort of like NSSystemClockDidChangeNotification available in Snow Leopard.

So bear with me here, because this is a strange idea and is definitely non-derterministic. But what if you had a watchdog thread running through the duration of your program? This thread would, every n seconds, read the system time and store it. For the sake of argument, let's just make it 5 seconds. So every 5 seconds, it compares the previous reading to the current system time. If there's a "big enough" difference ("big enough" would need to definitely be greater than 5, but not too much greater, to account for the non-determinism of process scheduling and thread prioritization), post a notification that there has been a significant time change. You would need to play around with fuzzing the value that constitutes "big enough" (or small enough, if the clock was reset to an earlier time) for your accuracy needs.

I know this is kind of hacky, but barring any other solution, what do you think? Might that, or something like that, solve your issue?

Edit

Okay so you modified your original question to say that you'd rather not use a watchdog thread because you are new to multithreading. I understand the fear of doing something a bit more advanced than you are comfortable with, but this might end up being the only solution. In that case, you might have a bit of reading to do. =)

And yeah, I know that something such as Photoshop pegging the crap out of the processor is a problem. Another (even more complicated) solution would be to, instead of having a watchdog thread, have a separate watchdog process that has top priority so it is a bit more immune to processor pegging. But again, this is getting really complicated.

Final Edit

I'm going to leave all my other ideas above for completeness' sake, but it seems that using the system's uptime will also be a valid way to deal with this. Since [[NSProcessInfo processInfo] systemUptime] only works in 10.6+, you can just call mach_absolute_time(). To get access to that function, just #include <mach/mach_time.h>. That should be the same value as returned by NSProcessInfo.

Hamamatsu

I really like the idea, but unfortunately I need to have Leopard (10.5) compatibility. It looks like Apple put everything useful in 10.6. ;) – Twit

This solution would be 10.5 compatible. You would in essence be implementing your own version of NSSystemClockDidChangeNotification, not using an Apple-supplied version. – Hamamatsu

Ah, I didn't read the whole thing. I saw NSSystemClockDidChangeNotification and thought "10.6 only :(". That'll teach me. ;) Yes, similar to the idea I added to my edit, and I like it, but would love something simpler of course. I'm thinking that, well, doing all of this shouldn't have to be necessary for something so trivial. On Linux you can simply read proc and grab the uptime from there, low-level. OS X must have a way of doing it. – Twit

How about [[NSProcessInfo processInfo] systemUptime]? Or does that also run into problems if the clock is changed? – Hamamatsu

Not 10.5 compatible, unfortunately. It does work perfectly in 10.6 though, even if the clock is changed mid-way. Whatever variable that's reading from the processor is what I need. BTW, I really appreciate your help Marc. I was checking out your profile and had a few friends who went to RIT. Very windy campus I hear. :) – Twit

One last try: mach_absolute_time(). That seems to return the same thing. #include <mach/mach_time.h> should be what you need to gain access. And yeah, RIT is absurdly windy. Good thing I'm not there right now. =) Fall is the worst for that (next to winter). – Hamamatsu