> From: John Cowan <[email protected]> > Cc: [email protected] > > [email protected] scripsit: > > > You are *forbidding* an implementation to increment > > the clock before a leap second? > > Yes, absolutely.
Assume for simplicity that the epoch is at the start of a minute which includes a leap second (at the end), and let's make a chart of the five SI milliseconds around the change of the last two seconds of that minute. If the time-and-date clock were an integer number of seconds, I would know how to not increment it. In that case, simply do nothing for one extra second (the leap second). 58 58 59 59 59 ... ordinary second 00:00:59 59 59 59 59 59 ... leap second ... 00:00:60 59 59 60 60 60 ... ordinary second 00:01:00 But if the time-and-date includes a count of milli-seconds, does that continue to increment? (choice A) 58.998 58.999 59.000 59.001 59.002 ... ordinary 59.998 59.999 59.000 59.001 59.002 ... leap 59.998 59.999 60.000 60.001 60.002 ... ordinary If so, then the time jumps backward by 1000ms. This is sure to cause trouble. Maybe the millisecond counter also hangs: (choice B1) 58.998 58.999 59.000 59.001 59.002 ... ordinary 59.998 59.999 59.999 59.999 59.999 ... leap 59.999 59.999 60.000 60.001 60.002 ... ordinary or maybe it runs at half speed for two seconds: (choice B2) 58.998 58.999 59.000 59.000 59.001 ... ordinary 59.499 59.499 59.500 59.500 59.501 ... leap 59.999 59.999 60.000 60.001 60.002 ... ordinary In either case, the millisecond counter has become completely useless for accurate interval timing, so what is it for? As I understand, NTP (Network Time Protocol) chooses A, the counter drops back, but it also keeps track of leap second indicators which show when a leap second is happening, so it is possible to unambiguously recover UTC and the table of past leap seconds, and so to compute accurate intervals. Unix time chooses B2, except that the timer does not run at half speed for two seconds, but slows unpredictably for an unknown interval. (At least I think so, from looking at some code. Your Unix may vary.) > UTC time is readily available (except during leap > seconds), TAI time is not. This is a strange thing to say. If you have UTC you get TIA (International Atomic Time) by simply adding the difference, which is always an integer and increments by one for each leap second. According to the International Earth Rotation and Reference Systems Service (IERS) bulletin C: > from 2009 January 1, 0h UTC, > until further notice : UTC-TAI = -34 s http://data.iers.org/products/16/13277/orig/bulletinc-040.txt So TAI = UTC+34 why is that hard? Modified proposal: (time-and-date) - return an integer count of non-leap seconds since the epoch. The epoch is <given in standard>. This can be used in calendar procedures. (seconds-on-timer) - return a real number, as accurate as reasonable, which is the time in seconds since the interval timer was reset. (time-of-reset) - an integer giving the time-and-date when the interval timer was reset (to zero). Maybe there should be a way to create timers, in which case those last two procedures need an argument (the timer). -- Keith Wright _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
