While the article in general is great, the author’s assumption of one true time is rather cute :).<p>At the very least, there are:<p>- the actual number of seconds that passed since the epoch, i.e. the number a perfect egg timer would show if you had set it off at 12 AM on 1970-01-01.<p>- International Atomic Time (IAT), the closest thing to the aforementioned egg timer we currently have (though with some offset, naturally).<p>- Terrestrial Time (TT), which is 32.odd seconds ahead of IAT, apparently for historical reasons.<p>- Universial Time (UT<timezoneoffset>), which is supposed to be the solar time at one particular location, Greenwhich for UT1.<p>- Coordinated Universal Time (UTC), probably the closest thing to The One True Time, which jumps around merrily depending on the rotational speed of Earth, trying to keep days of 86400 SI seconds.<p>Oh, and we’re not even considering relativistic effects here.
This bit makes me wonder about the entropy of the nanosecond clock, for adding entropy to an PRNG:<p>> Given scheduling jitter and so forth, it's not clear what it means to get a timestamp with nanosecond resolution from the operating system. It probably takes thousands, if not millions, of instructions between the time the timestamp is retrieved and the time your program looks at it
This article is:
1. Useful
2. Interesting
3. Actually has comments from people on the internet trying to get information in a polite and well explained manner. (WHAT?!)
It gets even more interesting when you put the machine into suspend, and time starts passing without timer interrupts getting serviced.<p>Or when NTP notices that your local clock is drifting, and attempts to discipline it.<p>As they say on the time-nuts listserv: A man with one clock always knows what time it is. A man with two clocks is never quite sure...
From 2010 but still interesting. Time an programming are inexorably intertwined, either by the time to do something is short enough, or the time when to do something is accurate enough. Having done some real time work (trying to get Linux running a robot back in the day) it was amazing at how challenging it was to keep things in sync. Given the cheapness of transistors there are a bazillion timers and clocks in ARM chips. At some point I expect to see a dedicated small core which does nothing but manage the observation of, and reporting on, the passage of time.
So let's say I want easy cross-platform access to a monotonic timer which gives me the number of egg timer (to use the phrase here) milliseconds since a certain UTC time. Assume that I've got an NTP server available to keep me somewhat near atomic reality, and let's neglect relativistic shenanigans. Is there such a function call?
It's not true that if you pass a pointer to a 'struct timezone' to gettimeofday() it just gets filled with zeroes - the tz_minuteswest field <i>is</i> filled with the current local timezone offset (based either on the TZ environment variable or on /etc/localtime).
If you think it's complicated in Linux, just try writing a mobile drag racing game for Windows 8.<p>If you try to index a GPS trace of a car driving the quarter mile by the system clock, good luck, because you can experience astonishing precision without accuracy.
I'm sad the newer time functions are still "esoteric"—it's the only sane POSIX timer API I'm aware of, but it's not available on Mac OS X or FreeBSD the last I checked.
I wrote a blog post about clocks and timers earlier: <a href="http://www.club.cc.cmu.edu/~cmccabe/blog_time_and_time_again.html" rel="nofollow">http://www.club.cc.cmu.edu/~cmccabe/blog_time_and_time_again...</a><p>It gets especially interesting when you start thinking about mutexes and condition variables with timeouts.