develooper Front page | perl.perl6.language.datetime | Postings from September 2000

Re: RFC 99 (v4) Standardize ALL Perl platforms on UNIX epoch

Thread Previous
Russ Allbery
September 28, 2000 16:38
Re: RFC 99 (v4) Standardize ALL Perl platforms on UNIX epoch
Message ID:
Curtis Jewell <> 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 (             <>

Thread Previous Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About