Concerning Time.TimeDiff

[Graham Klyne]

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