Time

[Ashley Yakeley]

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:

  <http://www.haskell.org/~simonmar/time/NewTime.html>
  <http://www.haskell.org/~simonmar/time/NewTime.hsc>

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 
timescale.

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 
orbit.

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.


Time Zones
----------

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.


Calendrics
----------

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.


Time Library
------------

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 
some issues:

* Basic types for time

Should there be different types for TAI/UT1/UTC? What about separate 
difference types?

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 
be needed?

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.

* Calendrics

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