[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Scheme-reports] current-posix-second is a disastrous mistake

On 12/15/10 10:09, Vitaly Magerya wrote:

>> The good news is that if we have monotonic TAI time we can
>> easily and unambiguously convert to POSIX time when needed,
>> to get around any compatibility issues.
> No, not easily. You can't use TAI to represent dates in the future,
> as it would require leap seconds tables that are only published six
> months before the leap seconds occur.

But we're not trying to represent dates; we're trying to represent the
pssage of time. We'd use a date object (which refers to a particular
calendar) to represent dates.

The date of my fortieth birthday is defined in the Gregorian calendar -
it's 2020-04-04. That date refers to a period of time that's about 24
hours long, but the mapping from that date to those two endpoint
TAI-seconds-since-epoch values is indeed as yet unknown.

This is not a problem.

> You can't use TAI to represent the current date either, as it would
> require current UTC-TAI difference, which most systems don't have [1].

Again, "current date" is a date.

> In short, as long as UTC is the basis of civil time keeping, TAI will
> not solve any problems.

It will solve the problem of knowing how many seconds elapsed between
two points in time, which is useful for all sorts of embedded control
systems that need to measure or maintain rates of various things
happening, ensure that important tasks are performed at least or at most
once per second, and so on, that videos and sound are played back at the
correct speed, and so on!

> The fact is, only a few people run ntpd, and only a small fraction of
> those who do ever bother to keep and update the leap-seconds file or
> to setup crypto keys and designate some servers as trusted. Therefore
> no widely available way of tracking current UTC-TAI difference exists.

Then perhaps Scheme distributions will come with a leap-second file, and
encourage its periodic updating. That shouldn't be too burdensome...


Alaric Snell-Pym

Scheme-reports mailing list