Speaking of which, if you really want to make your head hurt, read some of the articles published about how to standardize the keeping of time on computers. Adding and removing of leap seconds can be a big deal to processes that need accurate coordinated time across great distances, for logging, control and other purposes. Exactly how you define your Epoch beginning, and how you calculate an exact time from that Epoch date until today is really, really complex.
For instance, unix computers generally define the epoch as having begun at midnight, Jan. 1, 1970 UTC (microsoft uses 1/1/80 I think). Now, there have been a number of leap seconds added (and some subtracted) from that time until today. The time maintained on your computer is a count of the number of seconds since that date. I looked up the current time in seconds since the epoch and it shows it as being 1396582545. OK, now the question is, have the leap seconds been added to that number or not? Since 1972 there have been 25 leap seconds added to the calendar.
So, if I run that integer above through the unix 'date' command to determine what time it represents it shows the following:
$ date --date='@1396582545'
Thu Apr 3 22:35:45 CDT 2014
So, the question of whether leap seconds are included in that calculation is actually relevant. If they have not been, then the actual time represented by the number 1396582545 should have been Thu Apr 3 22:36:10 CDT 2014
Is it important? Well, if you're attempting to troubleshoot a network issue and are attempting to correlate logs from multiple systems that may not all implement the same algorythm for calculating that date, it could be relavant. A lot can happen in 25 seconds on a modern computer network.
The method that I'd propose to eliminate the uncertainty would be to implement a lookup table that contains a list of leap seconds similar to the following:
1961 JAN 1 =JD 2437300.5 TAI-UTC= 1.4228180 S + (MJD - 37300.) X 0.001296 S 1961 AUG 1 =JD 2437512.5 TAI-UTC= 1.3728180 S + (MJD - 37300.) X 0.001296 S 1962 JAN 1 =JD 2437665.5 TAI-UTC= 1.8458580 S + (MJD - 37665.) X 0.0011232S 1963 NOV 1 =JD 2438334.5 TAI-UTC= 1.9458580 S + (MJD - 37665.) X 0.0011232S 1964 JAN 1 =JD 2438395.5 TAI-UTC= 3.2401300 S + (MJD - 38761.) X 0.001296 S 1964 APR 1 =JD 2438486.5 TAI-UTC= 3.3401300 S + (MJD - 38761.) X 0.001296 S 1964 SEP 1 =JD 2438639.5 TAI-UTC= 3.4401300 S + (MJD - 38761.) X 0.001296 S 1965 JAN 1 =JD 2438761.5 TAI-UTC= 3.5401300 S + (MJD - 38761.) X 0.001296 S 1965 MAR 1 =JD 2438820.5 TAI-UTC= 3.6401300 S + (MJD - 38761.) X 0.001296 S 1965 JUL 1 =JD 2438942.5 TAI-UTC= 3.7401300 S + (MJD - 38761.) X 0.001296 S 1965 SEP 1 =JD 2439004.5 TAI-UTC= 3.8401300 S + (MJD - 38761.) X 0.001296 S 1966 JAN 1 =JD 2439126.5 TAI-UTC= 4.3131700 S + (MJD - 39126.) X 0.002592 S 1968 FEB 1 =JD 2439887.5 TAI-UTC= 4.2131700 S + (MJD - 39126.) X 0.002592 S 1972 JAN 1 =JD 2441317.5 TAI-UTC= 10.0 S + (MJD - 41317.) X 0.0 S 1972 JUL 1 =JD 2441499.5 TAI-UTC= 11.0 S + (MJD - 41317.) X 0.0 S 1973 JAN 1 =JD 2441683.5 TAI-UTC= 12.0 S + (MJD - 41317.) X 0.0 S 1974 JAN 1 =JD 2442048.5 TAI-UTC= 13.0 S + (MJD - 41317.) X 0.0 S 1975 JAN 1 =JD 2442413.5 TAI-UTC= 14.0 S + (MJD - 41317.) X 0.0 S 1976 JAN 1 =JD 2442778.5 TAI-UTC= 15.0 S + (MJD - 41317.) X 0.0 S 1977 JAN 1 =JD 2443144.5 TAI-UTC= 16.0 S + (MJD - 41317.) X 0.0 S 1978 JAN 1 =JD 2443509.5 TAI-UTC= 17.0 S + (MJD - 41317.) X 0.0 S 1979 JAN 1 =JD 2443874.5 TAI-UTC= 18.0 S + (MJD - 41317.) X 0.0 S 1980 JAN 1 =JD 2444239.5 TAI-UTC= 19.0 S + (MJD - 41317.) X 0.0 S 1981 JUL 1 =JD 2444786.5 TAI-UTC= 20.0 S + (MJD - 41317.) X 0.0 S 1982 JUL 1 =JD 2445151.5 TAI-UTC= 21.0 S + (MJD - 41317.) X 0.0 S 1983 JUL 1 =JD 2445516.5 TAI-UTC= 22.0 S + (MJD - 41317.) X 0.0 S 1985 JUL 1 =JD 2446247.5 TAI-UTC= 23.0 S + (MJD - 41317.) X 0.0 S 1988 JAN 1 =JD 2447161.5 TAI-UTC= 24.0 S + (MJD - 41317.) X 0.0 S 1990 JAN 1 =JD 2447892.5 TAI-UTC= 25.0 S + (MJD - 41317.) X 0.0 S 1991 JAN 1 =JD 2448257.5 TAI-UTC= 26.0 S + (MJD - 41317.) X 0.0 S 1992 JUL 1 =JD 2448804.5 TAI-UTC= 27.0 S + (MJD - 41317.) X 0.0 S 1993 JUL 1 =JD 2449169.5 TAI-UTC= 28.0 S + (MJD - 41317.) X 0.0 S 1994 JUL 1 =JD 2449534.5 TAI-UTC= 29.0 S + (MJD - 41317.) X 0.0 S 1996 JAN 1 =JD 2450083.5 TAI-UTC= 30.0 S + (MJD - 41317.) X 0.0 S 1997 JUL 1 =JD 2450630.5 TAI-UTC= 31.0 S + (MJD - 41317.) X 0.0 S 1999 JAN 1 =JD 2451179.5 TAI-UTC= 32.0 S + (MJD - 41317.) X 0.0 S 2006 JAN 1 =JD 2453736.5 TAI-UTC= 33.0 S + (MJD - 41317.) X 0.0 S 2009 JAN 1 =JD 2454832.5 TAI-UTC= 34.0 S + (MJD - 41317.) X 0.0 S 2012 JUL 1 =JD 2456109.5 TAI-UTC= 35.0 S + (MJD - 41317.) X 0.0 S
The date to be displayed can therefore be accurately displayed to the user because it could be calculated accurately on the fly.
Yeah, most people don't care about stuff like this, but it is important for engineers to understand that there are multiple standards of time out there. GPS does NOT use leap seconds. This is very important for GPS recievers to know.
Here's a blurb I pulled from another page...(USNO)
International Atomic Time (TAI) is a statistical atomic time scale based on a large number of clocks operating at standards laboratories around the world that is maintained by the Bureau International des Poids et Mesures; its unit interval is exactly one SI second at sea level. The origin of TAI is such that UT1-TAI is approximately 0 (zero) on January 1, 1958. TAI is not adjusted for leap seconds. It is recommended by the BIPM that systems which cannot handle leapseconds use TAI instead.
Coordinated Universal Time (UTC) is defined by the CCIR Recommendation 460-4 (1986). It differs from TAI by the total number of leap seconds, so that UT1-UTC stays smaller than 0.9s in absolute value. The decision to introduce a leap second in UTC is the responsibility of the International Earth Rotation Service (IERS). According to the CCIR Recommendation, first preference is given to the opportunities at the end of December and June, and second preference to those at the end of March and September. Since the system was introduced in 1972, only dates in June and December have been used. TAI is expressed in terms of UTC by the relation TAI = UTC + dAT, where dAT is the total algebraic sum of leap seconds.
The first leap second was introduced on June 30, 1972. The historical list of leap seconds can be found here.
The Global Positioning System (GPS) epoch is January 6, 1980 and is synchronized to UTC. GPS Time is NOT adjusted for leap seconds.
BEFORE THE 2012 LEAP SECOND: GPS-UTC IS 15 (GPS IS AHEAD OF UTC BY 15 SECONDS)
AFTER THE 2012 LEAP SECOND: GPS-UTC WILL BE 16 (GPS WILL BE AHEAD OF UTC BY 16 SECONDS)
As of 1 January 2008, and until the leap second of June 30 2012
TAI is ahead of UTC by 34 seconds.
TAI is ahead of GPS by 19 seconds.
GPS is ahead of UTC by 15 seconds.
After June 2012,
TAI is ahead of UTC by 35 seconds.
TAI is ahead of GPS by 19 seconds.
GPS is ahead of UTC by 16 seconds.
I've been facinated by how computers keep time since I was taking a class on DEC Unix systems (longer ago than I care to mention) where it described how they had daemons that could keep an arbitrary number of computers in sync time-wise. It was pretty cool really, and predates NTP (Network Time Protocol). You would assign one system to be the Master. All other systems were Slaves to it. If for some reason the Master were to not be available for a certain interval, the Slaves would hold an 'election' amongst themselves and elect a new Master who would then take over those duties until/unless the original Master regained communication with the Slaves. That's almost exactly the terms used. At the time I thought it was funny.
That's probably more than anyone on this thread really wanted to know, but I'm bored, and this is something that interests me.
It's certainly more than I knew! So thanks for the update. It's fun to read ... as long as, you know ... no quiz!
I’ve noticed that the time at “Time.gov” is consistently 15 seconds faster than the clock on my computer.
Is that a network issue or something involving leap seconds?