I was probably a bit quick on the trigger there. Sorry!

It't been a while since I tried using CalendarTime and friends; I did have some difficulty making things fit, and eventually gave up the whole thing. My impression (which may well be a wrong one) was that others also had trouble adapting the library to their uses, too, and that the Time library was one of the less successful ones.

That may well be true, and I've heard others suggest that the library is inconvenient. I'm trying to get at whether that is due to current bugs in the implementation, or whether the design is fundamentally broken.

Looking at it now, possible criticisms could arise from the data types containing redundancy and non-uniqueness: e.g. one can easily construct non-consistent CalendarTimes,

Ok, I don't consider that to be a problem. The toClockTime operation should fail if the CalendarTime is inconsistent. Non-uniqueness isn't a problem: you can convert to a ClockTime which is unique. I think of the CalendarTime as a slightly more tractable representation of a date/time string; lots of date strings don't make sense either (eg. "31 February").

and there are multiple ways to represent the same interval as TimeDiff -- in fact, two TimeDiffs may or may not be equal, depending on what CalendarTime they apply to. (The 'deriving' of Eq makes this a moot point, perhaps, but seems to make equality rather non-intuitive)

I think this is the wrong way to look at it: two TimeDiffs should be equal if and only if all their components are respectively equal (i.e. the deriving Eq meaning). This is different from saying that "the effect of adding this TimeDiff is the same as adding this other TimeDiff", which depends entirely on what you're adding it to. So this cannot lead to a sensible meaning for Eq on TimeDiff. Ah - I've just realised one problem with the design. If you have a TimeDiff with multiple non-zero components (eg. one hour and one second), then the order in which you add them makes a difference, and this order isn't specified by the spec. That's probably why TimeExts has only single-unit differences. And another thing: it should be specified that diffClockTimes gives a TimeDiff in units of seconds & picoseconds, because these are the only forms of TimeDiff that have the same meaning independent of what ClockTime they are added to.

It seems that TimeDiffs perform two functions; deltas for ClockTimes (in the functions) and intervals of calendar times (specification of the data type), and I'm not sure it's a good idea to mix those.

I think TimeDiffs are deltas for ClockTimes only. Why do you say they are intervals of calendar times too? If we were to have an operation which adds a TimeDiff to a CalendarTime, then its meaning should be the same as converting the CalendarTime to a ClockTime, adding the TimeDiff, and converting back to a CalendarTime again.

Oh well. I'm not using Time at the moment, so its not an issue that will ruin my holiday for me :-)

me either :) Cheers, Simon