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

[Kerry Shetline]

> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20210426/c105e73c/attachment.html>