time since the epoch

[Peter Thiemann]

    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