Front page | perl.perl6.language.datetime |
Postings from September 2000
Curtis Jewell <csjc05@mizzou.edu> writes: > Hmm... Isn't TAI->UTC RELATIVELY easy, but has accuracy loss? (I could > be misinformed...) I'd just do two things, therefore: TAI to UTC is easy and accurate if you have a current leap-seconds table. (In fact, in order to get TAI, you probably converted from UTC to TAI in the first place, since most available clocks tick UTC.) The problem with doing anything about leap seconds other than completely ignoring them is that you have to know when they occur, and they're not predictable in advance. The accuracy problems with UTC are more discontinuity problems than anything else. The problem with UTC is that it behaves very poorly from the perspective of a computer program around leap seconds. Actually, it's more complicated than that: UTC is really a specification of a human time scale; it's not defined in seconds since anything. It's defined in terms of hours, minutes, seconds, days, months, and years. Leap seconds are well-defined in that sort of system; the clock just ticks from 11:59:59 to 11:59:60 and then to 00:00:00. The problems with UTC are all caused by *conversion*; most Unix systems currently convert UTC into seconds since epoch without adjusting for any leap seconds. All Unix clocks are natively TAI, given that they don't adjust for leap seconds and tick forward one second every second. However, since most people actually keep UTC or a time zone based on UTC, what actually happens in practice is that when there's a UTC leap second, the Unix clock blissfully ignores it and then finds itself one second off of UTC after the leap second has passed, at which point xntpd or the like adjusts the clock as if it had skewed. This means that if you were measuring something during a period in which UTC had a leap second, your measurement may well end up off by a second depending on what xntpd did to your clock. (This is just my understanding from reading a lot of mailing list traffic and web pages on this; I may well have some of the details wrong and welcome corrections.) > 1. Define $time->tai (and the corresponding $time->utc) routine... > 2. STORE time as TAI (for accuracy), but RETURN it in "integer" SCALAR > context (I assume other object methods return string SCALARS) as UTC > (for consistency). Of course, specifying $time->tai overrides this, and > the UTC value may be cached as needed to make this faster. I like this idea. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>Thread Previous