[time-nuts] FreeBSD, NetBSD, or Minix-III?

Poul-Henning Kamp phk at phk.freebsd.dk
Tue May 19 08:22:31 UTC 2009

```In message <20090519095316.1e1f4b46.attila at kinali.ch>, Attila Kinali writes:
>On Sat, 16 May 2009 15:09:07 +0000

>Out of pure interest: what makes handling of time difficult?

That people don't think about it the right way.

I think the biggest challenge for people to wrap their head around,
is that you can and should use a binary fraction instead of a decimal
fraction.

People are so used to thinking about milli-, micro- and nanoseconds
that they simply fail to recognize those as presentation formats for
an underlying real number.

Time is, for all we know, a continuous scale, it does not come in
small countable parcels, so the correct and ideal format is a
floating point format, not a fixed point format.

Time values have about 20 significant decimal places in regular
computer operation these days: subtracting two nanosecond resolution
timestamps will get you there, because of our choice of epoch for
time_t.

That _almost_ fits into a 64 bit integer in 32.32 format, even if
you choose to do the decimal fraction stupidity and let the fraction
count nanoseconds.

NTP does that or example.

However, we run out of seconds in slightly less than 30 years time
that way, NTP can live with that, it's packets are short lived,
but permanent records in an archive can not.

A 33.31 format would buy us a century, still allow us to get
nanoseconds right, but it be computationally inconvenient and
looks messy, so people balk at it.

It would get my vote however because it is the difference between:

int64_t t0, t1, dt;

[...]
dt = t1 - t0;

and
struct timespec t0, t1, dt;

[...]
dt = t0;
dt.tv_sec -= t1.tv_sec;
dt.tv_nsec -= t1.tv_nsec;
if (dt.tv_nsec < 0) {
dt->tv_sec--;
dt->tv_nsec += 1000000000;
}
/* XXX: still left with a two-component time difference */

The truly long term solution is IEEE 128 bit floating point format,
you can resolve 10000 years to femto-seconds and still have 7 decimal
digits of precsion to play with.

Poul-Henning

--
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

```