A lot of people have been talking about technical issues that arose from the leap second introduced at the end of 2016, one of the biggest and most notable players was CloudFlare, who wrote up a post-mortem of the leap-second issue that took down their DNS for a couple of hours. As a software engineer reading that post is a little scary because a lot of the time we don’t even think about what the system might be doing while our application runs.
After reading about CloudFlare’s issues I decided to go out and read up on the time APIs provided by the various languages I use — to see how these issues can be avoided.
Depending on what you want to accomplish there are two main approaches to avoiding time-based problems — if your system time can change in the middle of your application then you could see anything from your log timestamps jumping around to operations taking negative amounts of time, or objects being marked deleted before they were even created. How these issues are handled is situation-specific, and it’s down to the programmer to determine whether they will present a problem — it could be that there’s no issue at all, or it could simply mean checking for the possibility of a negative elapsed time between operations.
If what you’re doing is measuring the elapsed time between two points within a single application then what you may need is a monotonic or steady clock — a clock which will always flow forwards regardless of the underlying system time. The important thing to note about this type of clock is it is generally only useful for measuring an elapsed duration and not individual time points as monotonic clocks generally do not specify an epoch from which to count. The point here is that while our usual Unix Timestamp based clocks give us useful information about what the current time is, the definition of ‘current time’ is subject to change and so aren’t good for reliably measuring the time elapsed between two points. As a side-effect the values you obtain from a monotonic time source probably aren’t portable across machines and may not be portable across processes depending on the implementation.
The rest of this post focuses on the various monotonic clock APIs available in the different languages with which I’m familiar — after all if we’re not aware of them it’s difficult to know when and how to use them. Before we get too deep in to the various languages I should say that I’m not an expert on these matters, so any corrections or better alternatives are welcome.
Since C++11 the language has included the new <chrono> header which provides a selection of time-related classes, most notably 3 different clocks — std:system_clock for obtaining the real time, std::steady_clock for accurately measuring elapsed time (this is the monotonic clock), and std::high_resolution_clock which may or may not be steady and may or may not reflect system time. This makes it relatively easy to choose a clock that provides whatever features you require.
Note: An earlier version of this post claimed that MSVC were providing a std::steady_clock that wasn’t steady, this was the case up until MSVC14 (Visual Studio 2015) when the issue was fixed. Thanks to /u/tambry for the correction.
Java provides it’s relatively well-known Calendar and Date classes for doing date/time manipulation, but these are all focused on real time. To obtain a monotonic clock the only API I’ve found is System.nanoTime, the documentation provides a summary of the issues around this method, but the one you really need to be careful not to accidentally fall over is that successive calls more than 292 years apart may return incorrect results due to numerical overflow, so restart your processes once in a while.
Python 3.3 introduced the time.monotonic() function to provide a basic monotonic clock. Before python 3.3 there’s a pypi module called monotonic that provides similar functionality.
This is an interesting one, as I can’t imagine there’s typically been much call for this type of functionality in the browser. Is is however available in modern browsers through window.performance.now() — part of the relatively recent high resolution time specification, and provides a clock that is both high resolution (sub-millisecond) and monotonic.
Under Node.JS this API doesn’t exist, but it does provide it’s own version — process.hrtime(), available since well before v0.10 also provides both a high resolution and monotonic clock.
It’s been a little while since I’ve had to write any, but having a look through the documentation I couldn’t locate an appropriate function. I did find this bug report requesting one, and that referenced this PECL module but it’s not entirely clear whether that module’s timers are monotonic. It’s a bit disappointing since all the other languages I checked seem to provide this functionality as standard — even JS.
These are contributions people have made to this list through comments / replies.
POSIX provides clock_gettime() function which can take CLOCK_MONOTONIC parameter:
This clock represents the monotonic clock for the system. For this clock, the value returned by clock_gettime() represents the amount of time (in seconds and nanoseconds) since an unspecified point in the past (for example, system start-up time, or the Epoch). This point does not change after system start-up time.
std::time::Instant is a monotonic clock.
The OSICAT-SYS package contains a GET-MONOTONIC-TIME function.
Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising &sponsorship opportunities.
To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.
If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!