[time-nuts] FW: Bulletin C number 30
cfmd at bredband.net
Mon Jul 4 18:10:32 EDT 2005
From: "M. Warner Losh" <imp at bsdimp.com>
Subject: Re: [time-nuts] FW: Bulletin C number 30
Date: Mon, 04 Jul 2005 15:16:26 -0600 (MDT)
Message-ID: <20050704.151626.55342255.imp at bsdimp.com>
> In message: <220.127.116.11.0.20050704164921.03e4bc68 at mjs.alientech.net>
> mikes at flatsurface.com (Mike S) writes:
> : Much the same can be said of leap years (or more correctly, days).
> : The mechanics are similar Feb 28>Feb 29>Mar 1 is fundamentally no
> : different than 23:59:59>23:59:60>00:00:00, it's just adding to the
> : appropriate count on an exception basis. The only difficulty is
> : communicating the need and keeping track, since they occur
> : "randomly." There is a mechanism in place for the former, and the
> : latter isn't particularly difficult.
> Leap days are predictable. Leap seconds aren't. Everyone deals with
> leap days because they have been around for thousands of years. Leap
> seconds haven't and are random. That's a fundamental difference.
Actually, the Gregorian calender (with leap-days) was introduced in 1603, so we
have (just) 400 years of experience with it. Also, the leap-days have been
predictable so far, but the frequency correction is not quite right, and the
long term frequency drift will require a change in the system eventually.
But, for the near-term future (expected lifetime of software we write now), you
are most probably right. There was a great article PTTI a few years back on the
earth rotation issue if I recall correctly.
There are a number of systems which do have the flaw that they are unable to
give UTC-TAI or for that matter UTC-systemtime (such as GPS) which is indeed a
flaw in the system and anyone implementing anything relating to it will suffer
(as you do). Some systems or signals do not even support leap seconds, some
have changed and indicate them. In a general sense it is a mess.
More information about the time-nuts