When writing about time and software development, most people think of time zones. This Youtube video does a pretty good job of explaining why time zones can become such a nightmare for developers. Recently, I stumbled upon a whole different issue with time and software.
Sourcetoad develops a lot of software for the cruise industry. Time on cruise ships is an interesting dilemma. As cruise ships pass time zones, the time must change. However, it would be very confusing for passengers if the time suddenly changed in the middle of the day as the ship moved.
Imagine walking to a dinner reservation at 6:30 PM. You leave at 6:15 PM. When you get to the restaurant, the maître d’ says you have arrived an hour early. The ship crossed a timezone at 6:20 PM, and changed time to 5:20 PM. The average passenger isn’t going to be able to keep track of this. Instead, the ship’s time is controlled by a person. This person chooses convenient hours to adjust the time, mostly at night. In other words, the ship sort of has its own time zone.
This “custom” time zone causes a problem for systems that must display the time. How do the systems know what time to display? Luckily, there is a time server on the ship that sends out both UTC and the “Ship’s Time.” This information can be used in various ways for the application to know the correct display time. The easiest way is to set the application’s server to UTC, but point it at the ship’s time. If forced updates are on, as soon as the ship’s time changes, the server’s UTC time will change. The server will now know the correct time to give to the application.
The problem with this setup is that servers don’t expect their UTC time to change. UTC is supposed to be constant everywhere in the world. Time zone changes are fine, but the UTC timestamp should never change. We recently had an application that, when the UTC time changed, seemed to freeze for an hour. Once the time moved forward to where it was before the change, the application resumed functioning. It turned out, this application was using callback times based upon the system clock. When the system clock moved back, it was as though we set the callback to fire in an hour vs. 10 seconds.
I began looking for a solution to this problem, fearing there might not be one. The proper answer might be, “UTC time shouldn’t change.” Luckily, it turned out there was an answer in the form of Monotonic time. Unlike a UTC timestamp (which starts January 1st, 1970), Monotonic time starts at an arbitrary point. It cannot move backwards. Finally, and most importantly, it is completely independent of the system clock: changes to the system clock will not affect a monotonic time.
Using a monotonic time for our callback resolved the issue, but this is a very special use-case. In almost all applications, UTC should not ever move. So why do monotonic timers exist, and when are they commonly used? As it turns out, in high-precision environments, the system clock is not a reliable way to time events. System clocks can drift over time, and when a service such as NTP updates the clock to the reference, it can cause errors in precision measurements. Also, monotonic time functions generally return higher precision times. This means they can be used for measuring very small intervals, where the system clock is not granular enough. For example, in JavaScript, both the system time and the monotonic time is returned in milliseconds, but you can see the difference in precision:
console.log((new Date().getTime())); 1474991522515 console.log(window.performance.now()); 74891.05500000001
Are there places your software is using the system clock that it should be using a monotonic timer? Maybe it’s not a big deal, but it might be worthwhile to use one the next time.
