This web page documents an e-mail message sent to the LEAPSECS mailing list on 2003-04-22.
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 my Delta T page.
For a detailed history of time measurement see my time scales page.
For more details about the ongoing ITU-R process to abandon leap seconds see my online bibliography.
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