JavaScript IANA date/time library, now with support for leap seconds, TAI, TDT
About two months ago I released the first major version of @tubular/time, a JavaScript/TypeScript npm package for date/time handling, with solid support for IANA timezones, including dealing with weird edge cases like 47-hour days and negative DST and such. I’ve just finished up adding a feature I’ve always wanted to have in a date/time package, and that’s the ability to properly handle and represent leap seconds. Along with that comes conversion to and from TAI (International Atomic Time) and astronomical time systems. https://www.npmjs.com/package/@tubular/time One interesting issue was how to handle a broad range of years (thousands of years forward and backward in time) in a way that was nicely integrated with Universal Coordinated Time. The idea for UTC got something of a wobbly start around 1960, and wasn’t implemented in its current form until 1972. Going forward in time, UTC is only strictly defined for up to six months beyond the next announced leap second, or next announced lack of any leap second on the way. 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. * From 1957-1958, using a sliding weighted average, UT1 transitions to proleptic UTC. * 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. * 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. * 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. * A sliding weighted average transition from UTC to estimated UT1 follows for the next 365 days. * Formulaic predicted UT1 is used for all later dates and times thereafter. Another project I’ve been working on (which isn’t quite ready for prime time because it’s utterly without documentation) is a new JavaScript timezone compiler. This has replaced an old Java project I used for generating the timezone data used by @tubular/time: https://github.com/kshetline/tubular_time_tzdb
Kerry Shetline <kerry@shetline.com> wrote:
I’ve just finished up adding a feature I’ve always wanted to have in a date/time package, and that’s the ability to properly handle and represent leap seconds. Along with that comes conversion to and from TAI (International Atomic Time) and astronomical time systems.
I'm flattered that you thought my suggestion for proleptic UTC was worth implementing, but I'm not sure it's a very good idea - at least it has significant caveats. My aim back then was to sketch what might be a reasonable way to bridge between pre-atomic time and UTC, for code that can only support an integer offset between UTC and TAI. If your code supports rubber seconds then it should probably use the USNO table that records the rate and phase offsets between 1962 and 1972. (I don't know another source of that table, nor where you can get a copy while maia.usno.navy.mil is down.) For times in the future, beyond the expiry time of the leap seconds table, I think an API should refuse to return an answer. It's a category error to support future conversions between TAI and UTC or POSIX time for a couple of reasons: * TAI is a retrospective timescale; it isn't defined in the future. * There is a fixed, defined relationship between POSIX time and future calendar dates and times, but that isn't true for TAI. * Both these things are also true for UTC, with the added complication that UTC can't be represented as a linear count of seconds. Even if you support rubber seconds, there's a gap between 1958 and 1962, which you can either fudge or return an error as for times in the future. If you don't support rubber seconds then it's most sensible to return an error for any time before 1972. In general I'm not enthusiastic about the idea of using "TAI" in computer systems to avoid the complications of UTC, mainly because most computers don't have access to anything like TAI, so you end up with a fudge that still has the problems of UTC but papered over with a leaky abstraction that tries and fails to hide the truth. Tony. -- f.anthony.n.finch <dot@dotat.at> https://dotat.at/ South Biscay, South Fitzroy: Cyclonic mainly northeasterly 3 to 5, increasing 6 at times. Slight or moderate in south Biscay, moderate or rough in south Fitzroy. Thundery showers. Good, occasionally poor.
On Mon, 2021-04-26 at 17:17 +0100, Tony Finch via tz wrote:
In general I'm not enthusiastic about the idea of using "TAI" in computer systems to avoid the complications of UTC, mainly because most computers don't have access to anything like TAI, so you end up with a fudge that still has the problems of UTC but papered over with a leaky abstraction that tries and fails to hide the truth.
Tony.
I have always assumed that the problem of having access to TAI was solvable, using the same mechanisms that let computers know about time zones. From the application's point of view, TAI would just be another zone, with the mechanism for converting between TAI and UTC in a library. Am I overlooking something? Could you say more about your lack of enthusiasm for using TAI to avoid the complications of UTC? John Sauter (John_Sauter@systemeyescomputerstore.com) -- get my PGP public key with gpg --locate-external-keys John_Sauter@systemeyescomputerstore.com
John Sauter <John_Sauter@systemeyescomputerstore.com> wrote:
I have always assumed that the problem of having access to TAI was solvable, using the same mechanisms that let computers know about time zones. From the application's point of view, TAI would just be another zone, with the mechanism for converting between TAI and UTC in a library.
Am I overlooking something?
I think the things that are missing are: * A standard representation of TAI (as discussed in this thread). There's some convergence here already: I believe PTP matches POSIX time at the start of 1972, and counts TAI seconds after that point, which matches the tz "right" zones. But there isn't a solid meaning outside the period of 1972 - present. * A standard API for getting the kernel's idea of TAI and its leap indicator - something like a simplified ntp_gettime but aimed at applications rather than ntp daemons. Applications need to see the leap indicator so that they can tell if the kernel's idea of leap seconds matches the application's idea. They might differ if NTP isn't working or if NTP uses leap smear. * A standard way to obtain the leap second table. This requires some combination of either the tzdist protocol or normal software updates, combined with support in tz for using TAI without stepping in the "right" timezone swamp. Repeat for each language's standard library. Windows is supposed to have TAI support but I haven't looked into how it works. Tony. -- f.anthony.n.finch <dot@dotat.at> https://dotat.at/ Fair Isle, Faeroes: East or northeast 4 to 6, occasionally 7 at first. Slight or moderate in eastern Fair Isle, otherwise moderate or rough. Showers. Good, occasionally moderate.
On Mon, 2021-04-26 at 19:40 +0100, Tony Finch wrote:
I think the things that are missing are:
* A standard representation of TAI (as discussed in this thread).
There's some convergence here already: I believe PTP matches POSIX time at the start of 1972, and counts TAI seconds after that point, which matches the tz "right" zones. But there isn't a solid meaning outside the period of 1972 - present.
The obvious choice is to also count TAI seconds before 1972. Is there a problem with doing that? The customary zero point for the integer used by PTP is 1970, though some users of a count of SI seconds set the zero point to 1958. If you want to name times before the zero point you will need to handle negative values, is that your concern?
* A standard API for getting the kernel's idea of TAI and its leap indicator - something like a simplified ntp_gettime but aimed at applications rather than ntp daemons.
Applications need to see the leap indicator so that they can tell if the kernel's idea of leap seconds matches the application's idea. They might differ if NTP isn't working or if NTP uses leap smear.
It is very difficult for an application to overcome errors in the kernel. I think the most we can expect is that an application detect that the kernal has a problem and refuse to run until it is fixed. For example, if the Linux kernel's adjtimex function is disabled, an application which needs to detect if a leap second is in progress is out of luck, and should fail with an error message.
* A standard way to obtain the leap second table. This requires some combination of either the tzdist protocol or normal software updates, combined with support in tz for using TAI without stepping in the "right" timezone swamp.
This doesn't sound impossible, though I grant you it would take some effort, and there doesn't seem to be anyone with the contacts, skills and motivation to get it done at the moment.
Repeat for each language's standard library.
And also repeat for each operating system.
Windows is supposed to have TAI support but I haven't looked into how it works.
I believe Microsoft Windows has support for UTC, including leap seconds after 2018. John Sauter (John_Sauter@systemeyescomputerstore.com) -- get my PGP public key with gpg --locate-external-keys John_Sauter@systemeyescomputerstore.com
I'm flattered that you thought my suggestion for proleptic UTC was worth implementing, but I'm not sure it's a very good idea - at least it has significant caveats.
My aim back then was to sketch what might be a reasonable way to bridge between pre-atomic time and UTC, for code that can only support an integer offset between UTC and TAI. If your code supports rubber seconds then it should probably use the USNO table that records the rate and phase offsets between 1962 and 1972. (I don't know another source of that table, nor where you can get a copy while maia.usno.navy.mil is down.)
My goal was to maintain the +/- 0.9s relationship between TAI and UTC back to 1958, before transitioning to, as you call them, “rubber seconds”. While higher accuracy would indeed be possible using the USNO tables as you suggest, for my purposes (and I would suspect for many other users), the +/- 0.9s accuracy is good enough. Anyone needing more accuracy probably wouldn’t use a library such as mine anyway, but would instead, I imagine, use application-specific code to get the accuracy they need.
For times in the future, beyond the expiry time of the leap seconds table, I think an API should refuse to return an answer. It's a category error to support future conversions between TAI and UTC or POSIX time for a couple of reasons:
* TAI is a retrospective timescale; it isn't defined in the future.
Perhaps I’m mistaken, but I thought TAI was simply a count of well-defined atomic clock seconds, both forward and backward in time (with everything else like years and months and hours, etc., being mere conventions of formatting on top of a single numerical value). This is true for TDT (aka TT, Dynamic Time, etc.) used by astronomers, and AFAIK there’s a simple relationship that TDT = TAI + 32.184s. To understand my own use cases, I’m using this library behind the scenes at skyviewcafe.com <http://skyviewcafe.com/> so that users can enter dates and times as UT (or their own IANA timezone, which is merely window dressing on top of UT), and get results back in UT, without making a strict distinction between UTC and UT1. Internally the code needs both UT1 and TDT for various calculations, and this library facilitates those time conversions with what is already greater accuracy than the 1-minute precision of the user interface (at least backward and forward a few centuries). I’m also using this library for a Raspberry Pi astronomy/weather clock (https://github.com/kshetline/aw-clock <https://github.com/kshetline/aw-clock>) which is capable of displaying leap seconds when they occur. (Leap seconds might be abandoned in 2023, however, before the clock ever gets a chance to do its special leap second display!). For this purpose, the exact whole-second, non-rubbery regime of my conversion scheme is useful.
* There is a fixed, defined relationship between POSIX time and future calendar dates and times, but that isn't true for TAI.
POSIX time is really just UTC without the leap seconds, isn’t it?
In general I'm not enthusiastic about the idea of using "TAI" in computer systems to avoid the complications of UTC, mainly because most computers don't have access to anything like TAI, so you end up with a fudge that still has the problems of UTC but papered over with a leaky abstraction that tries and fails to hide the truth.
I don’t have a problem with TAI being used internally by a computers for things like file timestamps and event scheduling, if that’s what helps prevent glitches when leap seconds are observed, so as long as the human-facing interface remains UTC.
On Mon, 2021-04-26 at 15:15 -0400, Kerry Shetline via tz wrote:
I’m also using this library for a Raspberry Pi astronomy/weather clock (https://github.com/kshetline/aw-clock) which is capable of displaying leap seconds when they occur. (Leap seconds might be abandoned in 2023, however, before the clock ever gets a chance to do its special leap second display!). For this purpose, the exact whole-second, non-rubbery regime of my conversion scheme is useful.
I love the way you display leap seconds on an analog clock face: https://shetline.com/video/leap_second_display.mp4. Based on the way the Earth has been rotating recently, the next leap second will be around the end of this decade, and it will be a negative leap second. John Sauter (John_Sauter@systemeyescomputerstore.com -- get my PGP public key with gpg --locate-external-keys John_Sauter@systemeyescomputerstore.com
John Sauter via tz <tz@iana.org> wrote:
Based on the way the Earth has been rotating recently, the next leap second will be around the end of this decade, and it will be a negative leap second.
Yikes! I have re-calculated the "PREDICTIONS" formulae from the latest Bulletin A and I get the numbers below (which agree with your statement). https://datacenter.iers.org/data/latestVersion/6_BULLETIN_A_V2013_016.txt 2022-01-01 MJD 59580 UT1-UTC -0.077349 +/- 0.015906 2023-01-01 MJD 59945 UT1-UTC +0.017592 +/- 0.031025 2024-01-01 MJD 60310 UT1-UTC +0.112533 +/- 0.043922 2025-01-01 MJD 60676 UT1-UTC +0.207565 +/- 0.055679 2026-01-01 MJD 61041 UT1-UTC +0.302505 +/- 0.066625 2027-01-01 MJD 61406 UT1-UTC +0.397446 +/- 0.076999 2028-01-01 MJD 61771 UT1-UTC +0.492388 +/- 0.086926 2029-01-01 MJD 62137 UT1-UTC +0.587419 +/- 0.096513 2030-01-01 MJD 62502 UT1-UTC +0.682360 +/- 0.105767 Tony. -- f.anthony.n.finch <dot@dotat.at> https://dotat.at/ Isle of Man: West or northwest 3 or 4, soon veering north or northwest, increasing northeast 5 or 6 later. Slight or moderate. Showers. Good, occasionally moderate.
On Mon, 2021-04-26 at 23:57 +0100, Tony Finch wrote:
John Sauter via tz <tz@iana.org> wrote:
Based on the way the Earth has been rotating recently, the next leap second will be around the end of this decade, and it will be a negative leap second.
Yikes! I have re-calculated the "PREDICTIONS" formulae from the latest Bulletin A and I get the numbers below (which agree with your statement).
https://datacenter.iers.org/data/latestVersion/6_BULLETIN_A_V2013_016.txt
2022-01-01 MJD 59580 UT1-UTC -0.077349 +/- 0.015906 2023-01-01 MJD 59945 UT1-UTC +0.017592 +/- 0.031025 2024-01-01 MJD 60310 UT1-UTC +0.112533 +/- 0.043922 2025-01-01 MJD 60676 UT1-UTC +0.207565 +/- 0.055679 2026-01-01 MJD 61041 UT1-UTC +0.302505 +/- 0.066625 2027-01-01 MJD 61406 UT1-UTC +0.397446 +/- 0.076999 2028-01-01 MJD 61771 UT1-UTC +0.492388 +/- 0.086926 2029-01-01 MJD 62137 UT1-UTC +0.587419 +/- 0.096513 2030-01-01 MJD 62502 UT1-UTC +0.682360 +/- 0.105767
Tony.
As a prelude to the negative leap second, I expect the IERS to issue a Bulletin D around the beginning of July this year to increase DUT1 from -0.2 to -0.1. This will be the first increase in DUT1 not caused by a leap second. John Sauter (John_Sauter@systemeyescomputerstore.com) -- get my PGP public key with gpg --locate-external-keys John_Sauter@systemeyescomputerstore.com
On 2021-04-26, at 13:15:22, Kerry Shetline via tz wrote:
...
* There is a fixed, defined relationship between POSIX time and future calendar dates and times, but that isn't true for TAI.
POSIX time is really just UTC without the leap seconds, isn’t it?
More precisely, POSIX time counts non-leap seconds since 1972-01-01t00:00:00 UTC. Is there a problem other than ambiguity: that 2016-12-31t23:59:60 UTC and 2017-01-01t00:00:00 UTC are represented by the same POSIX time? Doesn't TAI use the Gregorian calendar, so 2017:01:01t00:00:00 TAI is 2016:12:31t23:59:23 UTC. That's just a timezone convention -- the date may differ among various timezones. -- gil
On Mon, 2021-04-26 at 15:06 -0600, Paul Gilmartin via tz wrote:
On 2021-04-26, at 13:15:22, Kerry Shetline via tz wrote:
...
* There is a fixed, defined relationship between POSIX time and future calendar dates and times, but that isn't true for TAI.
POSIX time is really just UTC without the leap seconds, isn’t it?
POSIX says, in section 4.16, that time is counted from 1970. UTC didn't exist in 1970, so PTP (as specified in SMPTE ST-2059-2) specifies 1972 as the base date, with an offset of 63,072,010. If you try to convert the PTP integer into civil time for display purposes, you need to deal with the values 15,638,408 and 47,174,409. These correspond to the two leap seconds between 1970 and 1972 in Tony Finch's table: June 30, 1970 and June 30, 1971 at 23:59:60 UTC. John Sauter (John_Sauter@systemeyescomputerstore.com) -- get my PGP public key with gpg --locate-external-keys John_Sauter@systemeyescomputerstore.com
On Mon 2021-04-26T17:57:57-0400 John Sauter via tz hath writ:
If you try to convert the PTP integer into civil time for display purposes, you need to deal with the values 15,638,408 and 47,174,409. These correspond to the two leap seconds between 1970 and 1972 in Tony Finch's table: June 30, 1970 and June 30, 1971 at 23:59:60 UTC.
Except in Germany, and anywhere nearby where folks set clocks using DCF77: UTC (old) as determined by DHI was broadcast at 7h, 10h except Sunday 19h, 19h30m, 20h, 21h, 22h, 23h, 0h, 1h, 2h except Saturday and Sunday 1h and 2h only between March 1 and October 31 SAT as determined by PTB was broadcast at 6h11m to 6h59m 7h30m to 9h59m 10h30m to 10h59m and between minutes 11 and 29, 41 and 59 of every hour from 19h11m to 5h59m so that table of POSIX offset time depends on when you were listening to the radio to set your clock. And in China neither of the above systems. This was for 1970-01-01. Farther back in time the chaos was worse. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m
Paul Gilmartin via tz <tz@iana.org> wrote:
Doesn't TAI use the Gregorian calendar, so 2017:01:01t00:00:00 TAI is 2016:12:31t23:59:23 UTC. That's just a timezone convention -- the date may differ among various timezones.
Not "just", I'm afraid. When a timezone changes offset (e.g. to or from DST) the periods with different offsets follow directly one after the other. So, to avoid ambiguity when the clocks go back, you need to write down both the time and the offset. But when DTAI changed from 36 to 37 there was a one second gap, the leap second 2016-12-31 23:59:60. Instead of including a DTAI offset in the time, we disambiguate with a special :60 second. Tony. -- f.anthony.n.finch <dot@dotat.at> https://dotat.at/ Cape Wrath to Rattray Head including Orkney: East or northeast 4 or 5, occasionally 6 at first. Slight or moderate. Showers. Good.
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.
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. John Sauter (John_Sauter@systemeyescomputerstore.com) -- get my PGP public key with gpg --locate-external-keys John_Sauter@systemeyescomputerstore.com
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.]
On Wed 2021-04-28T23:38:59-0600 Brian Inglis via tz hath writ:
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.
Note that 1 ms = 0.5 m A 1 m accuracy for GPS requires less than 2 ms error in UT1. Reductions of data from the day of a VLBI campaign give UT1 accuracy around 1 microsecond. That is only available after correlation and degrades rapidly, but it is essential for the Event Horizon Telescope. The 100 ms steps in DUT1 were deemed adequate for celestial navigation and feasible to provide in 1971-02 as detailed in CCIR Report 517. That report was produced by folks unfamiliar with the magnitude of the stochastic processes and the limits of the sampling theorem so they supposed the maximum |UT1-UTC| could be maintained within 0.7 s, and they wrote that impossible-to-achieve limit into an international regulatory document as well as the design of radio time signal broadcasts.
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! ;^>
The Silmarillion is a laudable and detailed construction of a past that did not happen on this earth. Predicting the future evokes another plethora of aphorisms. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m
Thanks for the info. I installed the attached to mention this. As for leap second support into the past and future, that's a tricky business indeed. Maybe the API should come with error bars? But I don't know how you'd estimate the error. Admittedly even calendrical support is dicey sufficiently far into the past or future. Here's current tzdb: $ TZ=UTC0 date -r 36028797018963968 Sun Jun 13 06:26:08 UTC 1141709097 That's the current prediction, but it ain't a-gonna happen.
participants (7)
-
Brian Inglis -
John Sauter -
Kerry Shetline -
Paul Eggert -
Paul Gilmartin -
Steve Allen -
Tony Finch