The R7RS draft fixes a longstanding hole by adding the simplest possible time function: current-second, which returns the time since 1970 in seconds.
Unfortunately, it specifies that the timescale used is TAI. This is overspecification. The advantage of TAI over POSIX time is linearity (POSIX time jumps backward at leap seconds, so it's ambiguous, and time arithmetic gives incorrect results), but R7RS acknowledges that most implementations will compute it by simply subtracting a constant from their system clock. In addition to not being correct TAI and being gratuitously incompatible with POSIX, the resulting timescale remains ambiguous and nonlinear, so it has no advantage over POSIX time. Why specify a feature when you know it won't work?
I agree that the POSIX timescale is messed up, but this is not something languages can fix. As long as time is provided by the operating system, the choice of timescale is up to the operating system.
Also, time standards have historically been replaced fairly often, so Scheme risks specifying an obsolete standard which no one else uses. It's safer to simply leave the timescale and epoch unspecified, and let current-second be the system clock, whatever it is.
There's already a scale like that, the current-jiffy scale. The TAI scale is to match up with Real World time, and because it's not tied to the Earth and Sun, there isn't any reason it shouldn't be computable into the indefinite future.
ReplyDelete(I fought for Posix time myself, but lost.)
On 1970-01-01 there was no such thing as TAI. The recommendation to create an international atomic time scale did not occur until the CCDS meeting during 1970, and the authorization to do so did not occur until the CGPM meeting of 1971. Furthermore, on 1970-01-01 the difference between atomic time and universal time was 8.000082 s, not 10 s, so the origin of this Scheme time scale does not correspond to any thing that was in use.
ReplyDeleteIn implementations of current-second that include fractional seconds, like Chibi's, current-jiffy looks redundant (except maybe for performance, in Big Scheme). Fractional current-second is obviously the Right Thing for timing, since it doesn't have the overflow or jiffies-per-second issues fixed-precision timers do, and maybe it's not too expensive for most timing, since all it does is allocate a flonum (and not even that, in a nanboxed implementation)...
ReplyDeleteSteve: I was going to respond that this was discussed on scheme-reports, but apparently that discussion cites you. Proleptic TAI is a confusing way to specify an epoch, but is there a less confusing way? Maybe "the number of seconds since 1970-01-01 00:00:08.000082 UT (i.e. 1970-01-01 00:00:00 TAI, if TAI had existed then)"?
It is a bit confusing to use the Unix epoch with a non-POSIX timescale, although Alex Shinn says that's normal.
Given that no provider of time signals has ever supplied such a time scale, and that this time scale does not match TAI anyway, one may as well say "We're just making up our own time scale that looks sortof like TAI and it's up to you to figure out whether and how you'll use it." Contrast that with the US DoD who created GPS system time and an entire infrastructure to supply it but slyly worded things such that GPS time is defined as UTC, so they are technically in compliance with the ITU-R. Contrast that with the ATSC folks who simply declared that the time scale underlying digital TV broadcasts is based on GPS time.
ReplyDeleteSo ATSC is defined in terms of GPS, which is defined in terms of UTC, which is defined in terms of TAI — so they all use the same timescale, but attach different labels to it?
ReplyDeleteI think a nonstandard epoch isn't a huge problem (most programs don't care about the epoch), but specifying something that no one is expected to implement correctly is. At best, this will lead to a series of nonmonotonic POSIX-like timescales with different epochs, as implementations use POSIX time minus whatever the current TAI-UTC offset was. Or maybe implementators will ignore the requirement, since they don't understand it, and just use POSIX time. Either way, their documentation will incorrectly claim these timescales are TAI. How are multiple misdocumented timescales an improvement on an unspecified timescale?
Not mentioned here yet are the astronomical scales and the Chinese GNSS system Beidou.
ReplyDeleteIt's kindof too late to worry about multiple misdocumented time scales...
http://www.ucolick.org/~sla/leapsecs/amsci.html
ever asked a bunch of different people who use IEEE 1588 what their epoch is?
All respect to Steve's domain knowledge, but complaining about the anachronistic name is like saying that the statement "The Hebrew prophet Isaiah lived in the 8th century B.C." is false because he was called יְשַׁעְיָהוּ not Isaiah and nobody used the B.C. timescale back then.
ReplyDeleteMaybe a better solution would be to provide a mandatory POSIX-style current-seconds and an optional TAI-based variant. That way implementers would be a lot less tempted to provide an incorrect implementation of the TAI one.
ReplyDelete