Time

Peter Simons simons at cryp.to
Wed Jan 26 14:54:58 EST 2005


Bayley, Alistair writes:

 > So are there disadvantages to using, say, UTC, as the
 > underlying representation?

I really am not an expert, so take this with a grain of
salt. My understanding is that you can chose your poison:

 * If you need accurate arithmetic with time, you
   essentially have to use TAI because everything else is
   quite simply not continuous, so any kind of math with
   that is very difficult to get right. (How many seconds
   does an hour have in UTC? Well, depends on the hour.)

 * If you need to handle points in time (calendar dates),
   you essentially have to use UTC because in TAI the
   information "24282794" may designate a different point in
   time today than it does in half a year.

The representation you should use depends on what you are
trying to do. So the good news is: Whatever you do, you
lose.

A really good library will almost certainly need both
representations, plus the ability to convert between them,
plus the ability to estimate the potential error, plus a way
to update the table of leap seconds semi-automatically, etc.

To be honest, I wouldn't want to be responsible for that
task. ;-)


Marcin 'Qrczak' Kowalczyk writes:

 >> type TimeDiff = (Integer, Float)

 > With Float it gives 60ns of precision at the end of each
 > second, and more precision near the beginning of each
 > second.

You are right, of course. That's why I suggested the use of
the type class Fractional a bit later in my posting.

My suggestion is not to use Float -- or any other concrete
type --, it is to store seconds plus a fraction of a second,
because this representation is capable of representing
arbitrary precision as long as your fractional type does.
You can chose the accuracy you need by choosing your
fractional type without changing the representation per se.

If you decide to use "microseconds since the epoch" on the
other hand, that is not possible -- neither is it with
"seconds plus microseconds", like C's "struct timeval" uses.

I'm always reluctant to chose arbitrary limitations for the
user of the code; let the user make those choices, then it
is his fault when things go wrong. ;-)

Peter



More information about the Libraries mailing list