[email protected] (Tom Van Baak), > The February leap day is a useful analogy when describing leap seconds > to non-technical people. But when you get into the details the two are > vastly different.
A well-written list, thanks. One quibble, though: > 2) Past dates involving February can be handled with arithmetic. > Past leap seconds are handled with leap second tables. > > 3) Future dates involving February pose no additional computing > challenge. Future dates with leap seconds beyond a few months are > simply not possible, or possible only with error bars. The requirement for tables (and, correspondingly, the "impossibility" of dealing with future UTC dates more than a few months out) depends on what you're trying to do. You can *talk* about the dates, and you can do interval arithmetic with a precision of days, hours, or minutes, perfectly well. The only thing you need those leap second tables for, I think, is performing interval arithmetic with a precision of seconds. In particular, if right now it's 2017-01-05T01:56:13, I can obviously compute that (say) exactly three years from now is 2020-01-05T01:56:13, and I can even set a computer alarm to go off then, even if neither I nor the (suitably programmed) OS kernel that's tracking the alarm know in advance how many leap seconds there might end up being between now and then. _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
