Time

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