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

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

On 2010-12-14 07:33, Alex Shinn wrote:
> I've looked into this, and I must say I concur wholeheartedly.  I have
> no idea what the committee was thinking when they came up with
> POSIX time, but I can only assume they were under the influence of
> some substance for which the idea of time passing at varying speeds
> seems natural.

Wall clock time != physical time, as it is tied to Earth rotation.
As long as that remains the case, we'll always have leap seconds,
leap days or any other similar complications.

Think of wall clock time as an arbitrary set of labels attached to
physical time.

> 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.

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].

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

[1] To be clear on this, NTP does not transmit current UTC-TAI
difference by default. There is in fact "tai" field in ntptimeval,
but it is only updated by ntpd if it has a leap seconds table, which
it can obtain:
1) from a manually specified leap seconds file
2) from a trusted NTP server

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. 

Scheme-reports mailing list