# Epoch time vs. time of day

Among the frequently asked questions on the web are these:
• How to calculate the number of elapsed seconds (or 100 ns "ticks") since year 0001
(the epoch for Microsoft .NET time)
• How to calculate the number of elapsed seconds (or 100 ns "ticks") since year 1601
(the epoch for Microsoft Windows file time)
• How to calculate the number of elapsed seconds since year 1970
(the epoch for POSIX time_t, Unix time)
• How many (leap) seconds have elapsed (or occurred) since year 1900? 1601? 0001? 0000? Alexander conquered the world?
Below we see that there is no good answer, not even if the year is 1972...
 Jurisdiction date legally adopted UTC number of legally counted leap seconds legally elapsed seconds since 1972-01-01 UTC (ITU-R TF.460), TAI, PTP (IEEE 1588, ITU-T G.8265.1) duUTC nlUTC etUTC Germany duGermany nlGermany etGermany France duFrance nlFrance etFrance New Zealand duNewZealand nlNewZealand etNewZealand Australia duAustralia nlAustralia etAustralia Quebec duQuebec nlQuebec etQuebec United States of America duUSA nlUSA etUSA GMT, UT, NTP, POSIX (IEEE 1003.1), Canada (except Quebec) N/A 0 etGMT

In the table above time is from the javascript Date() of the web browser. It is only as accurate as the system clock and configuration.
Because javascript does not strictly conform to UTC this demonstration will not be correct during a leap second.

This table displays the futility of producing a single algorithm by which an epoch-based time scale can agree with the time scales in contemporary use.

This demonstrates that the question

What time is it?
is very different than the question
How many seconds have elapsed?
In practice the answer to the first question has been the same, to within a second, everywhere on earth, for over a century.
The answer to the second question depends on the jurisdiction.

To put it another way:

It is much easier to achieve worldwide agreement on what time it is right now than to achieve agreement on the meaning of every elapsed second throughout history.

Canada has an interesting situation starting 2009-01-01, for Quebec has adopted UTC, whereas the standard time acts of other provinces still refer to GMT.
The situation is even more confusing in some european countries. Some versions of the legal documents refer to GMT in one official language, and to UTC in another official language.

## How is UTC different than any other time scale?

In the radio broadcast time signals currently known as UTC the duration of one second is unrelated to the duration of one day. The notions of time and date are measured by separate methodologies, and the connection between the two is maintained by the leap seconds.

Prior to the 1960s all national metrology agencies had reset the national clocks ad hoc whenever their observatories indicated that to be necessary. During 1960 radio broadcast time signals started to be based on international coordination with cesium chronometers and afterwards the name UTC began to be used informally for the time scale. In 1972 the coordination changed to use leap seconds, and in 1974 the document specifying leap seconds was revised to include the name UTC as a name for the broadcasts.

One of the 1960s discussions about changing the technical basis of timekeeping happened at the 12th General Assembly of the IAU in Hamburg on 1964-08-28. The members of the IAU Commissions 31 (Time) and 19 (Rotation of the Earth) discussed the confusion about time among astronomers and physiscists. One statement from the session stands out (see page 304)

The distinction between time epoch and time interval is not clear to everyone.
The confusion of precision computer timekeeping that has ensued makes the above quote regrettably prophetic. Commission 31 produced an explanatory note attempting to clarify the situation which included the two goals that radio broadcast time signals had to satisfy:
• to indicate the calendar date and passage of days by measuring earth rotation to give Universal Time
• to provide atomic frequency and time interval between two events on earth by measuring cesium atoms to give SI seconds

Equating UTC with GMT was understandable from the era when only the national metrology agencies had the sorts of chronometers which could distinguish between mean solar seconds and SI seconds, and keep track of a continuous count of SI seconds over long intervals. On the other hand, creating a time scale where 86400 seconds is not related to one day, and failing to announce that abrogation of "what everyone just knows to be true about how time and date work" with crystal clear documentation, have proved to be decisions devoid of foresight. We now face the consequences of those decisions whenever information processing systems encounter a leap second.

## Why do the numbers differ?

They differ because of the different dates at which each jurisdiction legally adopted UTC as the basis for standard time.
Prior to that date the legal time of each jurisdiction was counting mean solar seconds. There are no leap seconds in mean solar time.
Subsequent to that date the legal time of each jurisdiction began to count SI seconds based on TAI with the leap seconds added into UTC.

There is an important but rather pedantic distinction between the number of legally elapsed seconds and the number of officially elapsed seconds. In almost all jurisdictions the national metrology agencies, observatories, and/or radio broadcasts interpreted their organizational mandate as allowing the use of UTC instead of GMT. Thus for official purposes they adopted UTC as of 1972-01-01, but this did not modify the legal time in legislative acts, statutes, etc.

(Denmark is a notable exception to the above. Danish law asserts that legal time is based on the Greenwich meridian. The Danish national metrology agency interprets the law so strictly that they have declined to operate an NTP server, for that would be providing UTC instead of GMT.)

## International agreements demand leap seconds in UTC (but international agreements do not require leap seconds in the broadcast time scale recommended by the ITU-R, if that is given a different name)

The advent of cesium atomic chronometers made it possible to coordinate the synchronization of worldwide radio broadcasts for the first time ever. Leap seconds were invented for UTC in order to broadcast seconds of uniform length without also disconnecting the count of calendar days from the rotation of the earth. This need for leap seconds is indicated the following statements from international agencies.

Since year 2001 the ITU-R has been considering whether leap seconds will continue to be part of UTC. The ITU-R has been unable to come to a decision for lack of a way of dealing with these international implications:

if UTC retains leap seconds
one calendar day counts one turn of the earth on its axis with respect to the sun
if UTC abandons leap seconds
one calendar day counts 794 243 384 928 000 hyperfine oscillations of cesium-133
In 2015 November the delegates to the ITU-R WRC-15 again decided not to decide whether they would redefine the notion of "calendar day" by abandoning leap seconds in UTC. Instead the ITU-R deferred the decision again until the WRC in 2023. The ITU-R also called for yet more studies of the issue by an alphabet soup of different international agencies, not one of which has any purview for how computers handle the counting of time and date.

## IEEE standards are inconsistent with each other

In the table above, PTP stands for Precision Time Protocol which is the IEEE Standard 1588, and POSIX is the IEEE Standard 1003.1.
Note that the two different IEEE standards require that their systems maintain two different counts of elapsed seconds. This is a fundamental problem with information processing systems that cannot be resolved because existing timestamps already use both conventions.

Note that ITU-T SG 15 has recommended the use of PTP in ITU-T Recommendation G.8265.1. In many respects this is the ITU-T saying that their systems no longer have interest in following ITU-R Rec. 460. Thus the ITU-T has tacitly ignored

• that its predecessor organization adopted UTC as their time scale for telecommunication activities in 1980-11 at the 7th Plenary Assembly of the CCITT
• the BIPM letter to the ITU on 2007-09-04/05 (in Document CCTF/09-27, the Report of the 18th meeting of the CCTF where the CCTF "stresses that TAI is the uniform time scale underlying UTC, and that it should not be considered as an alternative time reference" and proceeds to mention that they might suppress TAI

For practical purposes, over the long term, POSIX (IEEE 1003.1) has chosen to count the mean solar seconds of Universal Time (just plain UT, not UTC) which are subdivisions of calendar days measured by earth rotation.
POSIX did not choose to count the SI seconds of TAI measured by hyperfine transitions in cesium atoms.

If a manager of a Unix-like system decides to disregard the POSIX requirement for the count of seconds then everything else can be made self-consistent using off-the-shelf hardware and software. This is as simple as setting the Unix `time_t` to the value specified and provided by PTP systems and also using the "right" zoneinfo files. Doing this, however, imposes caveats on interactions with other systems as detailed here.

## There is no single retrospective time scale

Each jurisdiction has its own sovereign time scale. Various national systems for time distribution broadcast notably different times until the 1960s. (And alas, as seen above, these differences are not merely pedantic political/legal ones, but technical ones embodied in the protocols of operational systems.)

Until 1988 it was the mandate of the Bureau International de l'Heure (BIH) to monitor those broadcasts and publish the differences. Since 1988 the International Bureau of Weights and Measures (BIPM) monitors the differences between the various national versions of UTC which serve as the official time of each jurisdiction. Every month the BIPM publishes the differences between the various versions of UTC in Circular T. In some countries the national version of UTC(k) consistently differs from most others by many microseconds.

## There can be a single time scale in the future

### Computing systems already have a way to handle leap seconds

POSIX/Unix and other computing systems would be happier if this confusion were to end. POSIX already requires that systems be able to handle this via the same mechanism that handles daylight (summer) time. See a working example of handling leap seconds which also shows (NEW) IETF RFC 7808 tzdist, a protocol that enables even more systems to handle leap seconds. Also see other details of a POSIX fix.
The javascript in this web page is adapted from GPS, UTC, and TAI Clocks by tvb at leapsecond.com.