[tz] JavaScript IANA date/time library, now with support for leap seconds, TAI, TDT

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Thu Apr 29 05:38:59 UTC 2021


On 2021-04-26 10:42, John Sauter via tz wrote:
> On Thu, 2021-04-22 at 14:01 -0400, Kerry Shetline via tz wrote:
>>
>> I settled on the following scheme for resolving these issues, and I’m
>> curious what others might think about it:
>>
>> * For all dates prior to 1957, estimated UT1 is in effect. This is
>> most accurate back to 1600, for which there is sufficient
>> astronomical data for reasonable approximate conversions from UT1 to
>> TAI and dynamical time. Further back in time less accurate
>> approximations are in effect.
> 
> This is good if the software is dealing with time as shown by a civil
> clock, but not if it is dealing with time as a physical process.  For
> example, if you want to know when an object dropped from a particular
> height will hit the ground, you need to compute with fix-length
> seconds.  The drop and hit times can then be converted to civil time
> for display.
> 
> In looking at historical estimates of the rotation of the Earth based
> on astronomical observations of occulations and eclipses, I found that
> the values of UT1 are reliabe only since 1825.  (Nevertheless, my table
> of proleptic leap seconds goes back to the year -2000.)
> 
>> * From 1957-1958, using a sliding weighted average, UT1 transitions
>> to proleptic UTC.
> 
> I suspect it would be good enough, and less confusing, to make the
> transition to proleptic UTC abrupt.
> 
>> * From 1958-1972 proleptic UTC, as proposed by Tony Finch (
>> https://fanf.livejournal.com/69586.html), is used, with the first
>> non-official leap second occurring at 1959-06-30 23:59:60.
> 
> I have also used the work of Tony Finch in my proposal for a proleptic
> UTC with leap seconds.
> 
>> * From 1972 up until the latest updates provided by the International
>> Bureau of Weights and Measures, well-defined UTC prevails, with the
>> first official leap second occurring at 1972-06-30 23:59:60.
> 
> Obviously the right approach.
> 
>> * For a year to 18 months after the current time, or after the last
>> defined leap second (whichever is later), a presumed leap-second-free
>> span of UTC is projected to occur.
> 
> The IERS predicts UT1-UTC for 12 months in advance--you could use that
> to predict a leap second (or lack thereof) for the next 12 months.
> 
>> * A sliding weighted average transition from UTC to estimated UT1
>> follows for the next 365 days.

Many (especially catastrophic) natural phenomena alter earth rotation due to 
mass movement and redistribution, which may be influenced by rotation rates, and 
also affects them, often in the opposite sense.

That's why IERS can't "reliably" predict more than six months in advance, and I 
didn't see their published projections supporting the *last* leap second 
declaration, although we are not privy to when they pick the projections used to 
make decisions.

It also appears that UT1 can be "accurately" and "reliably" determined only to 
orders of milliseconds at any time, presumably why the DUT1 change announcements 
are made in 100ms increments, based on the likely trend.

> The IERS also publishes a projection of the future value of UT2-UTC
> which can be used for times more than a year in the future.
> 
>> * Formulaic predicted UT1 is used for all later dates and times
>> thereafter.
> 
> An alternative would be to use the future predicted values of UT1 to
> predict leap seconds.

That's what IERS do: see comment about Silmarillion! ;^>

Of course, if SI had used mean solar day length measurements based about 2000 
rather than about 1800 (how accurate could that have been?) to define the 
second, rather than presumably worry about how much work and data astronomers 
and physicists would have had to adapt, we would have had fewer leap seconds so 
far, and lower probabilities of corrections, although possibly higher 
probability of negative leap seconds.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]


More information about the tz mailing list