Epoch time vs. time of day

Among the frequently asked questions on the web are these: 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, TAI,
PTP (IEEE 1588)
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:

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.

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

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

POSIX already requires that systems be able to handle this

POSIX/Unix systems would be happier if this confusion were to end. See some details of a POSIX fix and a recipe for doing it right.
The javascript in this web page is adapted from GPS, UTC, and TAI Clocks by tvb at leapsecond.com.