This is the second part of a two-part post about measuring time. Part one is here.
Last time we discussed our familiar calendar, and the conclusion was that it is really messy. Well, then we should maybe make a better one?
This idea is much less crazy than it sounds. Of course, it would be very hard, if not impossible, to persuade the entire world’s population to switch to a better calendar. But there is point in having a special calendar to be used by tech people in solving problems that are hard enough even without all these leap years.
In the simplest possible calendar, time is a single real number. This number indicates how many [time units] have elapsed since [reference date]. Easy, right? Well, as you have probably already guessed, the answer is “wrong”.
The first people to adopt such calendar were astronomers. Their apparent lack of imagination resulted in the calendar being called Julian date. It is the number of days since noon GMT January 1, 4713 BC. Dealing with Julian date is simple; the only problem arises when one wants to convert between Julian and ordinary dates. This is done by using two extremely complex formulas, the more frightening of which is shown below:
There is even a joke among programmers that no living person understands the meaning of these coefficients.
Up to this point, I successfully avoided speaking about fictional calendars. However, now I can’t resist writing a few words about Stardate.
Stardate is used by humans and other intelligent species in the Star Trek universe. It is always a single real number, but other than that, the format of Stardate varies wildly between different series and movies. Let’s first focus on Stardates in The Original Series.
The first episode starts with Kirk saying “Captain’s Log, Stardate 1513.1”. The most interesting question is whether this is a real date that can be converted to something else or just a random number. We could find the answer by browsing Wikipedia or Memory Alpha, but that’s not how mathematicians do it. Instead, let’s compare the number of digits in Stardate and ordinary date.
Stardate has 5 digits, that’s easy. Date in Gregorian calendar has two digits for day, but the first one doesn’t go all the way up to nine, so it’s like half a digit. Month is also two digits, but the first one doesn’t really count because it is usually zero. Using the same logic, we can say that the year has 3½ digits. In total, we have 6 digits. Therefore, Stardate either has very low precision or, more likely, it is made up. Memory Alpha confirms that Stardates were indeed chosen arbitrarily.
Note: If you are in high school learning logarithms, try doing your homework like this. Your Math teacher will love it.
Since I am writing this post only days after Star Trek Beyond came out, I should probably talk about Stardate as it appears in the newest Star Trek movies. There is not much to speak about, actually: the integer part is the year, and the fractional part is, quite counterintuitively, the number of days since the start of a year. For example, 2233.04 means the fourth day of 2233.
Let’s get back to serious business. Single-number calendars are currently most widely used by computers. It would be great if all programmers agreed on one universal calendar, but they instead created a multitude of incompatible ones via the following scheme:
The only calendar that stands out from the rest is Unix time, used by all Unix-like operating systems. It uses the reference date (by the way, it is also called epoch) of January 1, 1970. The time increments by one every second, which is convenient, because it allows to drop the fractional part unless you need very high precision. Unix was not designed for such high precision, so it stored the time in a signed 32-bit integer.
Signed 32-bit integer can store a value between -231 and 231-1 inclusive. If you assign the highest possible number to a 32-bit variable and then try to increment it, one of two things will happen:
- You will get an error.
- The number will “wrap around”, and you will get -231. This option is much more likely than the first one.
In either case, it is obvious that everything will break when the Unix time overflows. But when will this happen?
The chart above suggests that 231 seconds are just under one century, so the overflow should occur a bit before 2070. More precisely, it will happen at 03:14:07 UTC January 19, 2038.
Fortunately, most systems manufactured today use 64-bit integers, so they should avoid all problems… except they don’t. Not long ago it turned out that iPhone stored dates in an unsigned 64-bit integer, which can only manipulate numbers between 0 and 264-1. When the phone needed to deal with a date before 1970, it wrapped around and broke down.
There is of course more to Unix time than overflow and underflow errors. For example, every time a leap second is introduced, programmers have a massive headache.
Also, having a birthday on January 1, 1970 can probably be as bad as having surname Null.
As I mentioned before, Unix time is not the only time standard used in computing. You can see a relatively complete list here.
Fortunately, most programming languages have a built-in date type, which takes care of more or less all issues that may arise. Use it; don’t try to make you own time libraries, because that way lies madness.
Live long and prosper.