This web page documents an e-mail message sent to the LEAPSECS mailing list on 2003-04-22.

A better version of the calculations in this e-mail, including plots, is in this earth rotation page.

Here is a web page with 3 simple pictures that explain how leap seconds affect timekeeping.

For a plots of the differences between various time scales which were available throughout human history, extrapolations into the future showing the effect of abandoning leap seconds, and a possible way to get leap seconds out of POSIX time_t while preserving operational systems see this Delta T page.

A detailed history of time measurement is in this time scales page.

More details about the ongoing ITU-R process to abandon leap seconds are in this online bibliography.

The POSIX standard for computer time and international legal systems are broken now

To see the underlying legal problem, and to watch any subsequent leap second happen on your computer (the one on 2008-12-31 was special for being the first leap second to happen legally in the US and Quebec) see this javascript showing elapsed time page.

See an implemented and tested way to fix POSIX systems if the ITU-R changes the name of the broadcast time scale.


The current UTC standard will fail after more than 1000 years

Yet among human conventions that is a very robust scheme which deserves respect.
Nevertheless, the ITU-R has been discussing abandoning leap seconds.

The option of abandoning leap seconds fails in only 600 years

Wikipedia folks: I am mystified that this page about leap seconds was selected instead of all the other, clearer pages listed above. I suggest the links above more than the text below.


From owner-leapsecs@ROM.USNO.NAVY.MIL Tue Apr 22 23:58:52 2003
Received: from [192.5.41.253] (juno.usno.navy.mil [192.5.41.253])
	by santo.ucolick.org (8.11.7+Sun/8.11.7) with SMTP id h3N6wkd11634
	for <sla@UCOLICK.ORG>; Tue, 22 Apr 2003 23:58:46 -0700 (PDT)
Received: from rom.usno.navy.mil by [192.5.41.253]
	  via smtpd (for santo.ucolick.org [128.114.23.204]) with SMTP; 23 Apr 2003 07:09:21 UT
Received: from ROM.USNO.NAVY.MIL (rom.usno.navy.mil [10.1.4.27])
	by rom.usno.navy.mil (8.12.8/8.12.5) with ESMTP id h3N6wiTA019123;
	Wed, 23 Apr 2003 06:58:45 GMT
Received: from ROM.USNO.NAVY.MIL by ROM.USNO.NAVY.MIL (LISTSERV-TCP/IP release
	  1.8e) with spool id 9405 for LEAPSECS@ROM.USNO.NAVY.MIL; Wed, 23 Apr
	  2003 06:58:44 +0000
Received: from TS-FW.usno.navy.mil (TS-FW.usno.navy.mil [10.1.1.3]) by
	  rom.usno.navy.mil (8.12.8/8.12.5) with SMTP id h3N6whT8019120 for
	  <LEAPSECS@ROM.USNO.NAVY.MIL>; Wed, 23 Apr 2003 06:58:43 GMT
Received: from geneva.ucolick.org ([128.114.23.183]) by TS-FW.usno.navy.mil via
	  smtpd (for rom.usno.navy.mil [10.1.4.27]) with SMTP; 23 Apr 2003
	  07:09:18 UT
Received: (from sla@localhost) by geneva.ucolick.org (8.11.6/8.11.2) id
	  h3N6wel10009 for LEAPSECS@ROM.USNO.NAVY.MIL; Tue, 22 Apr 2003
	  23:58:40 -0700
Date: Tue, 22 Apr 2003 23:58:40 -0700
From: Steve Allen <sla@ucolick.org>
To: Leap Second Discussion List <LEAPSECS@ROM.USNO.NAVY.MIL>
Subject: UTC is doomed
Message-ID: <20030423065840.GA9702@ucolick.org>
References: <20030411053945.GA1257@ucolick.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030411053945.GA1257@ucolick.org>
User-Agent: Mutt/1.4.1i
Sender: owner-leapsecs@ROM.USNO.NAVY.MIL
Precedence: list
X-Virus: Clean
Status: RO
Content-Length: 2913
Lines: 61

UTC, with leap seconds as we define it now, is doomed.

On Thu 2003-04-10T22:39:45 -0700, Steve Allen hath writ:
> DUT1            calendar year   grace interval
> 0.5 hours       2603            600 years
> 1.5 hours       3152            550 years
> 2.5 hours       3533            380 years
> 3.5 hours       3844            310 years
> 4.5 hours       4113            270 years
> 5.5 hours       4354            240 years
> 6.5 hours       4574            220 years

This used the Stephenson & Morrison millennia-long deceleration of 1.7
ms/day/century.  The deceleration since 1620 has been less, and that
would push the calendar years farther into the future.  If global
warming causes the ice caps to melt then the deceleration will be
somewhat larger.  If melting ice caps shut down the Gulf Stream and
cause a new ice age then the deceleration could be somewhat smaller.
If a supervolcano erupts or asteroid strikes, all bets are off.

It is, nevertheless, interesting to take a cue from Rob Seaman at
http://iraf.noao.edu/~seaman/leap/
and estimate when UTC is doomed.

The current rules for leap seconds require that they happen at the end
of a month, with primary preference for semiannual scheduling in June
& December, and secondary preference for quarterly scheduling in March
& September.

So far, only the semiannual primary preference has been exercised.
When LOD has increased such that two leaps are needed every year, then
the secondary preferences will begin to be needed.  When LOD has
increased such that 4 leaps are needed every year, then the monthly
options will begin to be needed.  When LOD has increased such that 12
leaps are needed every year, then UTC as we know it is doomed.

avg. recurrence of leap seconds         calendar year
1 / yr                                  1981
2 / yr                                  2142
1 / qtr                                 2464
1 / month                               3752

(Note that the recently decreased deceleration already invalidates
the long term prediction that we should already be experiencing
more than 1 leap per year.)

So, in 1700 years UTC as we now define it will become unworkable.  If
our descendants still choose to keep time using a Babylonian
sexagesimal scheme of 24 hours/60 minutes/60 seconds they will have a
choice to make.  They might choose to keep civil time using TAI
seconds with leaps happening really often.  They might choose to
employ two kinds of clocks, one using TAI for time-tagged events and
one using mean solar seconds for scheduling social events.

Under the current scheme for UTC even the primary preferences
should be adequate for over a century.  There's no need to rush.

--
Steve Allen          UCO/Lick Observatory       Santa Cruz, CA 95064
sla@ucolick.org      Voice: +1 831 459 3046     http://www.ucolick.org/~sla
PGP: 1024/E46978C5   F6 78 D1 10 62 94 8F 2E    49 89 0E FE 26 B4 14 93

Steve Allen <sla@ucolick.org>
$Id: HTMLutcdoomed.html,v 1.20 2014/03/14 04:27:28 sla Exp $