SM> I wrote a reply, but I don't really have anything new to say over what's SM> been said already, so I'll keep it brief instead. The copy of ISO8601 SM> that I looked at is here: SM> http://www.astroclark.freeserve.co.uk/iso8601/index.htm, but from what SM> you said I'm guessing you're looking at a different version. Oops, I guess I did. However, the 2000 version does not clarify matters much more. It does, however, make the distinction between day (= 24 hours) and calendar day (period until the same daytime is reached again). Regarding, time periods it only specifies the syntax, not the semantics. Oh well. SM> Anyway, to sum up: SM> - I agree that there should be a constant-duration time offset type. SM> However, TimeDiff does actually fuction perfectly well as one at SM> the moment, since diffClockTimes only fills in the seconds and SM> picoseconds fields. Ok. But there is the caveat that TimeDiff { ... tdSec :: Int ... } which will give rise to overflows in a few years. SM> - I believe a reasonable interpretation of the other fields of SM> TimeDiff is as base-dependent offsets. The current implementation SM> in GHC doesn't do this, but you can use TimeExts which SM> does. In addition, it does not muddle months, years, etc together into one TimeDiff value. This is a GOOD THING because you would have to specify the sequence in which the various items are added to the reference to get a well-defined behavior. SM> - Our implementation of ClockTime uses C's gettimeofday(), which SM> apparently is based a broken definition of the epoch. Oh well :-) IMHO, the TimeDiff data type is the source of all evil (in Time, at least). What about the following proposal for extending TimeExts: * Add a datatype data Duration = Duration Integer Integer * Define the operations addToClockTime :: Duration -> ClockTime -> ClockTime diffClockTimes :: ClockTime -> ClockTime -> Duration [[ and deprecate using them from Time ]] * Write an explicit specification for the remaining operators. This should not be much effort. [the overall goal being, of course, to phase out the Time module] For further cleanup, the stuff dealing with CalendarTime could be moved into its own module Calendar. And it would be very useful to have parsing functions like parseTime :: String -> CalendarTime [might have to be IO CalendarTime because the interpretation depends on the local time zone, etc] Cheers -Peter