At 11:21 02/06/03 +0100, Simon Peyton-Jones wrote:
The H98 Time module is probably broken in many ways.
Rather than try to fix it incrementally, I think it'd be most productive if the interested parties simply got together and agreed an interface for a new Time module, even if it's incompatible with the old one. Perhaps Graham is The Man!
I don't feel especially well-qualified, but if I can contribute in some
small ways...
I've taken another look at the Haskell Report description [1], and beyond
clarification of some points it doesn't seem obviously broken to
me. Others may have some views... a pointer to earlier discussion might help.
The only thing I see offhand that I'd be tempted to change is the TimeDiff
structure, in which I'd suggest dropping the tdYear, tdMonth fields, and
changing tdDay to ::Integer. (This still fudges the issue of leap-seconds
in time-differences, but I don't think any errors thus introduced would
affect any but the most specialized of applications.) [see comments below]
Thus, maybe something like this (which is indicative of a direction, not my
last word on this):
[[
data TimeDiff = TimeDiff
{ tdDay :: Integer -- -(maxInt*365) to +(maxInt*365)
, tdHour, tdMin, tdSec :: Int -- 0 to 23, 0 to 59, 0 to 61
, tdPicosec :: Integer -- 0 to 10^12-1
} deriving (Eq, Ord, Read, Show)
]]
Taking a wider view, I'd ask: what are the common uses for the Time
library? As I mentioned previously, I don't think it's realistic to try
and satisfy all possible uses, but the library should provide useful
functionality for most common purposes. Some use-cases that come to mind are:
- "human-scale" timestamps; attaching a time to information for the
purposes of providing additional provenance information to human
users. This purpose probably has little use for sub-second granularity.
- "computer scale" timestamps; attaching a time to information to ensure
unique identification. Monotonicity may be more important than strict
accuracy.
- Timed event generation in real-time systems
- "human scale" measurements of duration (e.g. days, and fractions
thereof); e.g. contract durations.
- "computer scale" measurements of duration (e.g. seconds and fractions
thereof); e.g. race timing.
I'd suggest that specialist applications, such as astronomical date
measurements (at exactly what date and time will be the next total eclipse
of the sun?) which have to take detailed account of interactions between
leap-seconds and calendar dates, or social event scheduling (the local
start-time of next XYZ conference of functional programming) which have to
take account of many time-zone complexities are not to be solved by the
Time library. I don't mean to suggest that, say, the CalendarTime data
structure not be useful for exchanging information with such applications,
but that the Time module not be expected to take account of arcane
calculations involving leap-seconds or time-zone differences.
I think that's enough of my rambling. In summary, I think a review would:
(a) scope the purpose of the Time module
(b) recommend small rather than extensive changes, and
(c) be more specific about describing the data and function semantics
#g
--
[1] http://www.haskell.org/onlinereport/time.html
-------------------
Graham Klyne