Yet again, we have a leap second being added to UTC to further complicate everyone’s lives. Well, that might be overstating it, but it sure complicates the lives of server and network administrators, among others. The notion is that leap seconds are required to keep UTC in sync with Earth’s rotation and to prevent our clocks eventually being so far out of sync that solar noon will be at midnight. That notion is wrongheaded in the extreme, though.We would simply use some adjustment to get from UTC to local time once it started getting far enough out of sync. Local time would still continue to be approximately related to mean solar time.
We have a mechanism for calculating the display time by adding a configurable offset to a reference clock. This is known as time zones and they offset against UTC. Time zones are not just simple offsets from UTC, though. They have complications such as Daylight Saving Time (not a typo!), the specific definitions of which change at political whims. And time zones aren’t always an integer number of hours offset from UTC. Not even half hours. Or quarter hours. Or necessarily even minutes. Nor are they necessarily constant over time. That means we need a mechanism to update the data files needed to keep track of changes in time zone definitions, and, get this, we have one that mostly works. Most operating systems use a version of the “standard” time zone data files which can be updated independently of the rest of the operating system. That means time zone data can be kept up to date as political realities change.
Why, then, don’t we just use a monotonic reference clock that doesn’t care about leap seconds. It just ticks along incrementing the time by one second every second with minutes whose lengths never change. This reference clock will obviously get out of sync with the actual world. After all, leap seconds exist for a reason. Then, using the same mechanism we already use to determine time zones and other time keeping weirdness, we can calculate leap second offsets. All that needs to happen is that the leap second data be distributed the same way time zone data is. Then, when a program just needs a difference in time between two points, it can use the reference clock without having to worry about weird things like the same second repeating or what have you. Otherwise, the usual mechanism for converting time to a particular “time zone” would be used to get proper UTC time with leap seconds, etc. And the best part of this: there would be no need for operating system kernels to have to deal with this unpredictable bullshit at all. It would all be handled in non critical path userspace libraries. Even NTP and its ilk wouldn’t have to deal with it and could just do what it does best – keep reference time synchronized.
Now I do recognize that this is unlikely to happen. Instead, we’ll have to continue with are current mess which is partly due to conflicting definitions of UTC in different specifications. (Like POSIX which defines a day in UTC as exactly 86400 seconds which obviously precludes leap seconds.) That means we continue to have things like “leap smears” and other creative means of handling leap seconds in a manner that doesn’t cause the world to break.
To be perfectly clear on what my ideal time keeping system for computers would be, I’ll describe it below. I should note that there is no reason a system cannot implement this and still be POSIX compliant!
First, the basic idea behind POSIX’s time scheme is sound. That is simply a system clock that counts the number of seconds since the start of some particular epoch which, in this case, is 2016-01-01 00:00:00 UTC. That epoch is as reasonable as any other. Obviously the system clock can keep time to whatever precision it is able to, be that seconds, milliseconds, nanoseconds, femtoseconds, etc. My ideal system will use the same idea for the system clock.
Second, the system clock will not have the notion of days, hours, minutes, years, or anything other than seconds, which happen to be the base unit of time used in SI units. It will count seconds with no regard for any external factors. No leap seconds, etc., will apply to this count. It will literally be “seconds since the epoch”.
Third, the system clock will be available to programs as a means of time keeping.
Fourth, any standard library functions that are defined to return UTC will have to consult a data file to discover what leap seconds need to apply based on the current time stamp. However, the operating system kernel will not have to be concerned about this. It can be entirely handled in userspace. If the definition of UTC is changed so that it doesn’t use leap seconds any more, then this process will simplify and the conversion list might become a constant.
Fifth, any standard library functions that work on time zones will have to deal with both leap seconds and the vagaries of time zones. How this is done will be up to the library. Again, the operating system kernel will not need to know anything about this.
Finally, and this shouldn’t need to be stated explicitly, an operating system is free to provide any additional clocks and time services it desires either as part of system libraries or the kernel. That means it can continue to provide the POSIX UTC based time calls and the like.
Now, here’s the really fun part. There are already time scales that meet my requirements for an ideal computer timekeeping system! For instance, the GPS and TAI clocks, neither of which bother with leap seconds. Isn’t that wonderful? We don’t even need to create Yet Another Standard™ to make this work!
As I said earlier, I have no illusions that this will actually happen. However, recent versions of POSIX have given programs the ability to access time sources that aren’t impacted by leap seconds (clock_gettime() with CLOCK_MONOTONIC for instance), modulo any bugs in implementations. That does mean that things are improving, at least for programmers that actually understand how to deal with time properly. Alas, that is a distressingly small minority, even among those working on things where time is critical.