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 PGP: 0FAA 69FF C083 000B A2E9 A131 01B9 1C7A DBCA CB5E