ashley at semantic.org
Sat Jan 22 02:14:26 EST 2005
There's been a lot of discussion here and other lists of replacing
System.Time, and indeed Simon M. is working on a replacement proposal:
Rather than talk about specific Haskell code, I'd like to discuss the
measurement of time in general, how these concepts might be expressed in
Haskell, and what people might want from a time library. Rather than
propose anything, I want to try to ask some of the right questions.
Scales of Time
First of all, there are two obvious ways of measuring time.
One is "clock time", "absolute time", or "atomic time", time as would be
measured by a perfect clock. The standard for this is "International
Atomic Time", or TAI, which is measured by an international system of
atomic and maser clocks under the auspices of BIPM. TAI was established
in 1955. The various clocks around the world are kept synchronised by
simultaneous observation of transmissions from GPS satellites, though
BIPM is considering other methods. In addition to distributing time
live, BIPM issues post hoc corrections to create an even more accurate
TAI is nothing more than a continuous count of "SI seconds", which are a
fixed period of time defined in terms of a particular physical process.
Nevertheless TAI is usually represented in "date and time" format, even
as those "SI days" drift away from real Earth days.
The other way is in terms of the earth's rotation against the sun. To
get an accurate and even timescale, the earth's rotation is measured
against the stars and distant radio sources, and then corrected for the
annual orbit of the earth around the sun. Doing this at a particular
place on the earth gives a version of "Universal Time" known as UT0.
Despite its name, UT0 varies from place to place due to the motion of
the poles. Correcting for polar motion yields UT1, which is a single
scale for all places.
Note that the sun itself may be up to 16 minutes off UT0 due to the
"equation of time", that is, the motion of the earth on its elliptical
UT1 is a continuous count of "Earth days". Since the earth does not keep
perfect time, the precise length of these days varies.
UT1 and TAI were synchronised at the precise beginning of 1958 as
observed at Greenwich. Since then, the two have drifted apart, with UT1
days being about 2ms longer than the "SI days" (= 86400 SI seconds) of
TAI. The difference between the two is currently around 32 seconds. A
parameter known as "Delta T" tracks the difference:
Delta T = TT - UT1 = TAI - UT1 + 32.184s
The current value of Delta T is about 64s. The offset constant of
32.184s has a historical reason: that and some of the other historical
details I've omitted. TT is something called "Terrestrial Time".
Neither UT1 nor TAI is used for civil time, however. Instead, a
timescale known as UTC was defined in 1972. Like TAI, UTC counts SI
seconds, and the difference is always an integer number of seconds
(currently 32). Like UT1, UTC does not drift with real Earth days, and
the difference is always kept with 0.9s. This is managed by inserting or
removing "leap seconds" into the timescale at the end of June or
December. The IERS is responsible for determining leap seconds.
Unfortunately, the earth's rotation is not very predictable. Indeed even
human actions such as damming large rivers near the equator are enough
to make a difference to timekeeping. As a result, the IERS gives only
six months' notice of its decision to adjust UTC or not. For instance,
leap seconds used to be regular insertions about every 18 months, but
there hasn't been one since the one at the end of 1998. All adjustments
so far have been insertions, though removals are also possible: David
Mills claims his popular NTP time distribution software can handle that,
though other software might potentially have problems.
UTC might be thought of as an integer count of days, together with a
continuous count of seconds. Most days have 86400 seconds in them, a few
have 86401, and some might have 86399.
So TAI, UT1, and UTC are the most commonly used timescales. Of course,
when it's daytime in one place, it's nighttime somewhere else, so local
"time zones" are defined. Time in each zone is a fixed offset to UTC,
usually a whole number of hours though in some zones (such as the single
one for all of India) it's on a half-hour. Each zone might nominally
refer to a meridian or line of longitude: while meridians are more
relevant to UT1, they give some notion of the accuracy of the time in
the zone as compared to the motion of the sun through the sky. The
meridian for Eastern Standard Time, for instance, is at 75dW, the one
for Pacific Standard Time is 120dW.
Confusingly, in some zones in the northern hemisphere, or some parts of
some zones, time is offset by an additional hour during some summer
period. The precise days in the year vary from place to place, and the
parts of the zones that are subject to this are not always simply
defined. For instance, the American state of Indiana has three separate
regions, with three different time behaviours: most of it uses EST
without summer offset, another part uses EST with an offset in the
summer, and another part uses CST with an offset in the summer.
Time zones informally have three-letter acronyms, however I believe
these are not standardised. Specifying the actual time difference is
standard in software protocols.
A calendar is a system of naming periods of time: usually these are
periods of days, though the boundary between named days may vary. A
calendar may be determinate or it may involve some kind of observation,
it may or may not track the year as defined in various ways, it may or
may not track the period of the moon with varying degrees of accuracy,
etc. It may involve one or more separate cycles, such as the seven-day
"week" cycle. It may have associated with it certain "special" days that
may be defined in related or unrelated ways.
It's worth noting that even the length of the year is not a well-defined
thing. The length of time between March equinoxes differs from the
length of time between June solstices and so on, since the solstices and
equinoxes are drifting relative to each other as they precess around the
ellipse of the earth's orbit.
So what does this mean for Haskell? Mostly that there is a very wide
range of time-related needs for various applications. Ideally a standard
library would help with some of these without prejudicing others. Here
are some things that I think ought to be kept in mind even though some
of them may be beyond the scope of a standard library, together with
* Basic types for time
Should there be different types for TAI/UT1/UTC? What about separate
What resolution should be used? Should we use fixed-point numeric types?
Should time types be parameterised by underlying numeric type?
* Converting between timescales
TAI/UTC conversion means knowing and predicting leap-seconds. This
information changes over the years. What about the backwards extension
of UTC to before it was created?
TAI/UT1 conversion means a function for the earth's rotation. This too
is dependent on changing information. What sort of approximations would
If both conversions are provided, would it be appropriate to provide
guarantees about the calculated difference between UT1 and UTC?
* Converting between different zones
Should a time-zone be a first-class object? What type would it use,
would a difference type be appropriate?
* Calculating summertime zone adjustments
This is probably a bit much for a standard library, especially as
official definitions change occasionally. Nevertheless, some thought
about this may be helpful. For instance, when Seattle moves from PST to
PDT, has it actually moved time zones? Or is it in the same time zone,
but switched "time offsets"? What's the best terminology?
* Getting the current time and zone
Which timescales should be available? Different platforms may have
different information available.
What about functions for working with Gregorian calendar information?
I'm guessing other calendars should probably be left to others.
* Displaying and parsing time in different zones
Which standard formats should be covered? Would a field-based "printf"
system be useful here?
* General organisation
Is it worth splitting it into more than one module?
Ashley Yakeley, Seattle WA
More information about the Libraries