SM> TimeDiff isn't a "duration", it's a way of specifying time offsets whose SM> duration depends on the base to which the offset is being added. If we SM> only had constant-duration offsets, then there would be no way to say SM> "give me a ClockTime for this time next Wednesday". [nitpicking] Oops, this is not the purpose stated in the library report: "The TimeDiff type records the difference between two clock times in a user-readable way." Anyway, the sort of specification that you are talking about is really a pain IMHO. Actually, you could not use TimeDiff to state it, either. [ISO8601 allows it but I think it's too imprecise to be useful] SM> The problem is really that all the different kinds of offset are lumped SM> into one type: there ought to be a TimeDiffSeconds, TimeDiffMonths, and SM> so on. TimeDiffSeconds is a constant-duration offset, but SM> TimeDiffMonths isn't. The problem with lumping them into one type is SM> that if multiple components are non-zero, you don't know in which order SM> to add them. It is always a problem to lump things with different semantics into the same type :-) What I'm arguing is that there should be only one fixed-duration offset datatype and it should be in terms of (seconds, picoseconds). Other fixed durations can be easily defined in terms of this datatype. I'm still not sure that you actually want base-dependent offsets, but again they can be easily defined on top of the fixed duration datatype. And they should be specified separately from the base functionality. Certainly, differences between clock times should be in terms of the fixed-duration datatype. SM> The TimeExts library gives you separate differences like SM> these, BTW. That sounds good, I'll look at it again (it's pretty much bare code, so I might have overlooked something). >> Unfortunately, with UTC, this goes on to make adding *anything* except >> seconds to certain ClockTimes (namely the instants of leap seconds, >> eg, what happens if you add 1 minute to 23:59:60 ? This is a perfectly >> legal UTC time on a day with a leap second) meaningless. SM> That's right, and here I'm not sure whether the right behaviour is to SM> raise an exception or to "roll over" to the next nearest date/time. I SM> believe TimeExts does some kind of rolling over, but I'm not sure of the SM> exact semantics (George?). As far as I read ISO8601 (which also has a notation for durations) this is unspecifed :-) And as far as I read TimeExts.lhs it does some sort of rollover. My take would be to specify the behavior for adding something like a TimeDiff to a base date in a consistent manner and then cast that in stone. If there is a (reasonable) standard for this kind of calculation, then this should be the basis for the specification. SM> Ok, ISO8601 seems to specify only constant-duration time intervals, but SM> allows them to be given in terms of years, months, days etc., where a SM> month is specified to be 30 days, it seems, and similar SM> approximations If I remember correctly, then ISO8601 specifies durations up to a day, but bails out at months and years. >> >> Agreed! So what is epoch? Is it >> "Seconds since 00:00:00 on 1 Jan 1970 [TAI]"? SM> I guess so... GHC's implementation will be whatever the C library uses, SM> which I assume is the one you specified above (at least on a decent SM> implementation). Unfortunately, if you are using time(2), then you'll get rubbish (from the manual page): DESCRIPTION time returns the time since the Epoch (00:00:00 UTC, Jan uary 1, 1970), measured in seconds. [...] NOTES POSIX.1 defines seconds since the Epoch as a value to be interpreted as the number of seconds between a specified time and the Epoch, according to a formula for conversion from UTC equivalent to conversion on the naïve basis that leap seconds are ignored and all years divisible by 4 are leap years. This value is not the same as the actual num ber of seconds between the time and the Epoch, because of leap seconds and because clocks are not required to be synchronised to a standard reference. The intention is that the interpretation of seconds since the Epoch values be consistent; see POSIX.1 Annex B 2.2.2 for further rationale. The problem is that this notion of time is discontinuous and sometimes not strictly increasing. See the various references pointed out by members of the list for why this can be a problem. -Peter PS, I see you are trying to follow-up to haskell-cafe, but I'm not subscribed to that list.