Newsgroups: comp.risks
X-issue: 17.08
Date: Sun, 23 Apr 1995 22:02:42 +0059 (EDT)
From: Robert J Horn <rjh@world.std.com>
Subject: Floating-Point Time

The opponents of floating-point representation for time have done an
insufficient analysis.  About twenty years ago I was part of a research
group doing extensive time series analysis of weather and related data.  We
needed a good way to represent time.  Fortunately we had a few astronomers
on the team, so time was reasonably well understood.

We chose "second of century", using a double precision floating point
representation.  Analysis showed that this would preserve millisecond
accuracy for the span of interest.  (Actually for all of recorded history
and more.)  Since we usually were satisfied with one minute accuracy this
seemed sufficient.  There was a brief debate about using a better time base,
but 12:00:01 AM GMT, 1 January, 1901 was easy to explain to everyone.  There
are a few applications that need better than millisecond precision, but for
most of the worlds applications double precision floating point will provide
enough precision for the next few millenia.  (A simple test for those who
are unsure about their needs.  Do you compensate for the variations in the
rate of the Earth's rotation?  If not, you probably don't need millisecond
accuracy.)

This notation had some interesting side effects.  At the time, floating 
point turned out to be somewhat faster than 64-bit integers due to a 
quirk of hardware.  It also led to excellent compatibility with the 
other time series processing.  Time was just another well behaved 
variable.  This notation eliminated a lot of the mistakes made by the 
typical programmer who is ignorant of traditional time notations and 
their problems.  There could have been some round-off issues, but we 
rarely did any arithmetic other than addition or subtraction of two 
times, where millisecond accuracy is maintained.  It even led to a 
simple notation for interval time span data, e.g. "0.01 inches of rain 
fell between 1633 and 1647 on ...", which is how many meteorological 
measurements are made.

The difficult problems were in translation to and from local.  The most
severe problem was the inherent ambiguity of local time in recent decades. 
There are two true times corresponding to each time in the one hour of
overlap when Daylight Savings shifts back to Standard.  Correctly
resolving this ambiguity was always a headache.  Fortunately most 
professional measurements have been recorded in UTC, or GMT before UTC 
was defined.

A word of caution, double precision floating point is suitable for an 
internal representation of UTC, or "absolute" time.  You have to do your 
own analysis if you are interested in timing relative to some event.

Rob Horn    rjh@world.std.com

P.S.  The turn of century problem has made The NY Times.  It may be so
widely hyped that almost all the problems are fixed by the time it comes.