Concerning Time.TimeDiff

[Ketil Z. Malde]

"Simon Marlow" <simonmar@microsoft.com> writes:

>   - ClockTime and TimeDiff are now represented as 
>     Integer picoseconds only.  Hence, they also now derive
>     Num, Enum, and Integral.

I think this is the most aesthetically pleasing.  From a practical
point of view, we should perhaps consider the possible need to
represent times of higher resolution, and the practical need to use of
much lower resolution.  Division by 10^12, or the need to push really
large integers around isn't going to end up being costly, is it?

>   - ClockTime is defined as picoseconds since the epoch, where
>     the epoch is defined in terms of TAI.

>   - calendarTimeToClockTime now returns a Maybe.

Okay, this is perhaps more "functional", but is it really what I want?
Wouldn't an illegal calendarTime often be a bug in the code, and if
so, isn't it better to just crash?  I don't much care for wrapping
things in Maybe, could we have an 'isCalendarTimeValid' instead (in
order to verify values that aren't static)?

I.e., isn't this 

        foo ct | isCalendarTimeValid ct -> ...calendarTimeToClockTime ct...
               | otherwise -> error ...

as useful as this
      
        foo ct = case calendarTimeToClockTime ct of
                Just t -> ....
                Nothing -> error ...

?  And of course cleaner in the cases where you *don't* need to check?

>   - I've commented out addDays and friends.  I assume that
>     there isn't an immediate demand for these functions, so
>     they can be left out until later, or moved to a separate
>     library.

-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants