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... ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
