Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 04 Jan 2006 01:57:50 +0100
From:      Carlos Amengual <listas@informatica.info>
To:        John-Mark Gurney <gurney_j@resnet.uoregon.edu>
Cc:        freebsd-current@freebsd.org
Subject:   Re: FreeBSD handles leapsecond correctly
Message-ID:  <43BB1D8E.1010204@informatica.info>
In-Reply-To: <20060104003637.GB69162@funkthat.com>
References:  <20060103120026.EEEC916A41F@hub.freebsd.org> <43BAE883.1090705@informatica.info> <20060103234638.GA69162@funkthat.com> <43BB15BB.2070705@informatica.info> <20060104003637.GB69162@funkthat.com>

next in thread | previous in thread | raw e-mail | index | archive | help
John-Mark Gurney wrote:
> Carlos Amengual wrote this message on Wed, Jan 04, 2006 at 01:24 +0100:
> 
>>John-Mark Gurney wrote:
>>
>>>so, the only fix for a sextant is a new table of numbers...  don't
>>>forget the tables HAVE to be updated for precisely the reason leap
>>>seconds are inserted...
>>
>>It is not only an update, it is a change in the tables themselves. And 
>>sidereal time would no longer be sidereal time.
> 
> 
> I mean how they are currently updated each year, not updated to use a
> new time scale..
> 

Dropping leap seconds would lead to the use of a timescale different to 
UT in tables.

Of course, a point could be reached where leap seconds are frequent 
enough to become a pain for computers. In that case, computers could use 
TDT as time scale, but we need to have UT one way or the other.

Astronomers regularly use TDT (formerly ET) as a work timescale, and UT 
only for Earth-orientation matters (Sidereal Time, which in fact defines 
UT). Computers could use TDT (not TAI, which AFAIK is not in "real" 
practical use elsewhere), but simply "freezing" UTC with the drop of 
leap seconds just adds confusion (another TAI-based timescale in 
addition to TAI itself and TDT). A "frozen" UT in current use is already 
invented: TDT.


Regards,
Carlos Amengual



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43BB1D8E.1010204>