The Second is now defined, in SI, by the physics of atoms, and no longer by the rotation of the Earth.
For the UTC time scale, the addition or subtraction of Leap Seconds accommodates the discrepancy in rate, which in 2001 was about 1 ms per day or 0.01 ppm. The UTC day thereby tracks the averaged rotation of the Earth with respect to the Earth-Sun line.
A constant rate of Leap Seconds would accommodate a constant averaged Earth rotation time differing from the nominal 86400 SI seconds. Variations in the Leap Second rate accommodate changes in the Earth's averaged rotation rate.
Long-term, the Earth's mean rotation slows by about 7 ms / year / year, largely because of the drag of sea-tides.
Leap Seconds occur simultaneously, world-wide, at UTC midnight.
Leap Seconds were introduced in principle at 1972.0 UTC; the first one was 1972-06-30 23:59:60 UTC.
Global Warming could, as a minor side-effect, influence Leap Seconds.
Leap Years are quite different; they deal with the relationship between the mean Solar Day and the period of the Earth's (or Moon's, for some calendars) orbit.
The International Earth Rotation Service, in France, decides and announces, a few months in advance, when a Leap Second will be needed.
Adjustment is at the end of June or December, UTC (March and September are second-preference but have never been used). All Leap Seconds so far have been positive. The short-term trend around 2004 had suggested to me that negative ones might be needed by 2010 or later, but the long-term trend must be for positive ones to be needed more and more often.
I have read :- Formally (ITU-R Recommendation TF.460), the rules are that a Leap Second can be inserted or removed at the end of *any* UTC month - Markus Kuhn.
A Leap Second is inserted, or omitted, at the end of the UTC day; it is immediately followed by the start of the next UTC day.
Ideal local clocks in different time zones will generally show different hours (and in some cases different minutes).
ISO 8601:2004 Section 2.2.2
has :-
NOTE
An inserted second is called positive leap second and an omitted second
is called negative leap second.
A positive leap second is inserted between [23:59:59Z]
and [24:00:00Z] and can be represented as [23:59:60Z].
Negative leap seconds are achieved by the omission of [23:59:59Z].
Insertion or omission takes place as determined by IERS,
normally on 30 June or 31 December, but if necessary on 31
March or 30 September.
From reliable sources :-
1972-1985, then: 1987-12-31 1989-12-31 1990-12-31 1992-06-30 1993-06-30 1994-06-30 1995-12-31 1997-06-30 1998-12-31 2005-12-31 2008-12-31 2012-06-30
Those were all positive; the given UTC day finished at the end of 23:59:60.
197 198 199 200 201 223344556677889900112233445566778899001122334455667788990011223344556677889900112233445566778899 ++.+.+.+.+.+.+.+..+.+.+...+....+...+.+..+.+.+..+..+..+.............+.....+......+.
BIPM have an authoritative list.
For more information, seek "Time Scales: UT1, UTC, TAI, ET, TT, GPS time" at http://www.stjarnhimlen.se/; and elsewhere, probably including maia.
IERS Bulletin C: Announcement of Leap Seconds in UTC :-
IERS Bulletin C 42, dateline Paris, 8 July 2011, seen 2011-07-10, included :-
NO positive leap second will be introduced at the end of December 2011. The difference between Coordinated Universal Time UTC and the International Atomic Time TAI is :
from 2009 January 1, 0h UTC, until further notice : UTC-TAI = -34 s
I find it amusing that, while IERS definitely stated that there would be "NO positive leap second", it made no explicit statement about the possibility of a negative one.
IERS Bulletin C43, dateline Paris, 5 January 2012, seen 2012-01-14, included :-
A positive leap second will be introduced at the end of June 2012.
The difference between UTC and the International Atomic Time TAI is:
from 2009 January 1, 0h UTC, to 2012 July 1 0h UTC :
UTC - TAI = - 34s
from 2012 July 1, 0h UTC, until further notice :
UTC - TAI = - 35s
Aha!
IERS Bulletin C 44, dateline Paris, 7 August 2012, seen 2012-08-22, included :-
NO leap second will be introduced at the end of December 2012. The difference between Coordinated Universal Time UTC and the International Atomic Time TAI is :
from 2012 July 1, 0h UTC, until further notice : UTC-TAI = -35 s
In the EU, legal time is generally UTC-based; but in the UK it is still, I believe, GMT-based, though time signals etc. are UTC-based.
In the USA, H.R. 2272: 21st Century Competitiveness Act of 2007, SEC. 3570. METRIC SYSTEM DEFINED, makes legal time UTC-based (it was solar-based) (Risks 24.79).
The GPS time scale has no Leap Seconds; thus it is diverging from GMT/UTC; see gpsinformation.net, USNO. GPS-UTC is currently transmitted as a signed 8-bit quantity; a change will be needed before the difference exceeds that range, which is expected to occur in the second half of the current century.
See Risks Digest 24.02/9; and on this page.
Changes have been suggested, including the abolition of Leap Seconds and the use of Leap Hours.
A meeting of the International Telecommunications Union in January 2012 on the abolition of Leap Seconds has postponed any decision until 2015.
A special interest group ought not to be deciding a matter of importance to the general public.
The main use of time is to regulate ordinary life, for which days should be both of seemingly constant length and locked to the Mean Sun. But for scientific and technical purposes, (SI) seconds of truly constant length are needed.
Astronomers, navigators, and maybe a few others, have some special wants; they should sort those out amongst themselves without allowing their particular wishes to dominate those of the majority.
There should thus be one primary time signal, giving a SI seconds count and thus Hertz. Signals can be derived locally to distribute New Greenwich Mean Time and current local offset information. Any receiver can use the latter to give local civil time without ambiguity.
The exact relationship betwen NGMT and the SI seconds count will be known for all times up to a few months into the future. Therefore an NGMT standard clock can be set from the SI signal and a knowledge of applicable rates.
† I suggest that the Zero Second should be Gregorian -10000-03-01 00:00:00 New Greenwich Mean Solar Time (BC 10001 March 1.0 NGMT). For that, the seconds count will be positive through all history, and it will have 12 decimal digits from BC 6832 until AD 21688. Starting on the day after a "400 year" Leap Day simplifies conversion to conventional date.
‡ An SI-rate seconds signal and a phase-locked loop can be used to give a civil-rate seconds signal; or vice versa.
When the seasons have drifted significantly by the Gregorian Calendar, one or more extra Leap Days (positive or negative) will be needed. That is substantially what was done in the change from the Julian to the Gregorian Calendars; the Pope decreed ten negative Leap Days, the King later decreed eleven. A Leap Day seems equivalent to 86400 Leap Seconds occuring at a single instant.
2008-02-20 :
The standard should not be UT, but it should be indistinguishable from UT for all purposes apart from high-precision time measurement.
Aside : The Olympics, etc., should specify SI time.
Civil Time should run at a rate of one CT second for every N SI nanoseconds, where N is an integer announced (early in each half-year, to apply for the following half-year) by BIPM in a replacement for Bulletin C.
Since we've been using one leap second, or not, about every 16 megaseconds, it is clear that integer SI nanoseconds per CT second gives ample resolution. The six-month interval will be as satisfactory as the Leap Second interval, and can be reduced in the same manner when needed.
Given disseminated SI seconds, it is easy enough to generate SI nanoseconds locally, to count them, and to generate CT seconds accordingly.
The exact implementation of a change of rate would need to be carefully defined; for example whether it is done on the CT or SI half-year.
If desired, the rate-change could be spread out by changing the integer by one unit at a time; it's only simple electronics such as I used to build from SSI & MSI, and could easily be integrated on a single chip of specified properties.
The above is essentually equivalent to having a number of Leap Nanoseconds every second, but smooths them out.
It has been also suggested that there should be Leap Milliseconds instead of Leap Seconds. They would be so small that only experts would notice them, and usually so frequent that those who need to remember about them would have little time to forget.
The following block of information came from NPL UK (before mid-1997), but any errors are mine. Their unlinked French URLs seem now not anonymous-accessible - use IERS at the Observatoire de Paris.
Length of Day - UTC
The present definition of UTC, with the difference between UTC and TAI being an integral number of seconds and the use of leap seconds, has been in operation since 1 January 1972. There have been twenty positive leap seconds so far with the twenty-first scheduled for the end of June 1997 (end of June in UTC time, not BST time!). There have been no negative leap seconds (i.e. no 86,399 second days) since UTC was established in its present form.
Length of Day - UT1
I agree with your general comments on the possibility of negative leap seconds and on the slowing down of the earth. However, you may wish to consult the International Earth Rotation Service (IERS) web pages for more quantitative information.
The IERS site is ftp://hpvlbi.obspm.fr/iers/ierscb.html which includes brief information on the earth rotation parameters (ftp://hpvlbi.obspm.fr/webiers/general/earthor/ROT.html) and on UT1 ftp://hpvlbi.obspm.fr/webiers/general/earthor/utlod/ut1.html) including the duration of the day from 1623 to the present (see table 3).
See also "Leap Seconds" at NPL.
"The International Earth Rotation Service (IERS) is an interdisciplinary service that maintains key connections between astronomy, geodesy and geophysics".
IERS Bulletin C, which is normally released in January and July, is "either to announce a time step in UTC, or to confirm that there will be no time step at the next possible date".
See their "When should we introduce Leap second in UTC ?".
About IERS Bulletins :-
Leap Seconds occur immediately before UTC midnight. Thus, by UK Civil Time (which in practice is UTC in Winter and UTC+1 in Summer), Winter Leap Seconds end at midnight, and Summer ones end at 1 a.m.
The UK formally uses GMT; thus our New Year formally starts during a positive Leap Second, when there is one in UTC December (NPL).
"The Pips" are a broadcast time signal used in the UK. See Greenwich Time Signal. They start at :59:55 and continue until :00:00; so normally there are six, the last always now being longer.
My Web site is for general use. Therefore, I use the term UTC to mean UTC, with SI seconds; and I use GMT for time which tracks the rotation of the Earth, has exactly 60×60×24 seconds per day, and agrees with London Winter Time. I understand that UT (Universal Time) is, for experts, the right term for the latter; but it seems to me that it is too likely not to be understood, or to be taken as a typo.
The difference between GMT and UTC should never exceed 0.9 seconds.
The terms UTC and GMT are often used, for example by the developers of JavaScript, as if synonymous.
Legal time in the UK (and in the USA) is GMT. In the UK, time signals are, however, UTC.
Historical changes in GMT are generally disregarded.
There are three types of computer system or subsystem :-
Most applications do not need UTC. In ordinary life, it is sufficient to elide UTC into GMT, and to have 60 seconds in every minute. But, of course, it is necessary to allow for Summer Time, with days of 23/23½/24/24½/25 hours; and, because of Leap Years, years of 365 or 366 days.
Applications written on the basis of every minute having sixty seconds, whether or not backed by an applicable standard, are liable to error when run in an environment affected by Leap Seconds, in at least these ways :-
MS-DOS and Windows (as far as I know, at least up to XP) know nothing of Leap Seconds, using GMT. Unless an application needs Leap Seconds, it is only necessary to arrange that synchronising routines which may receive Leap Seconds to not present them to the OS.
UNIX-type systems often can understand Leap Seconds; this can cause problems with applications that do not.
POSIX.1 specifies that Leap seconds are ignored.
A JavaScript Date Object holds a count of integer milliseconds from UTC 1970-01-01 00:00:00.000 = 0.
ECMA-262, 3rd Edn, Sec 15.9.1.1, says "Leap seconds are ignored".
It appears that at least some Linux browsers get the OS to convert between Y M D h m s and milliseconds; and that the OS, having access to a Leap Second database, can include Leap Seconds in the conversion.
Since code, including my code, commonly assumes 24×60×60×1000 = 864e5 milliseconds per day, peculiar results can ensue.
Test cases :-
Additionally, JavaScript is required to use, for all dates, the Summer Time Rules for the current date. In the UK, the third of those tests should show 00:00:00 UTC, although at that period our clocks were one hour ahead of GMT.