time since the epoch

[George Russell]

Simon PJ wrote (snipped)
> Meanwhile, I suspect there's an opportunity for someone (or a small
> group) to suggest a new Time library that really does the business, and
> provide an implementation.  If it's sufficiently persuasive, all the
> implementations will adopt it and it can become a de-facto standard.
I already have written a TimeExts library which is in fact bundled with GHC,
namely in -package lang.  What I ought to do, I
suppose, is fishify the comments so Haddock can produce something useful.

Basically it allows you to add a time difference to a ClockTime value to
get another ClockTime value, or subtract two ClockTime values to get a time
difference.  The time difference can be a number of picoseconds, seconds,
minutes, hours, days, months or years.

For all but seconds and picoseconds, it does this by converting to CalendarTime
(using toUTCTime), doing complicated Gregorian calendar calculations (I am
not proud of the code here), and then converting back using toClockTime.
This is probably not a very good way of doing it but at least no-one has
complained about it so far.  Which means either it's perfect or no-one uses
it, I fear the latter.

At least it might be a good idea to start with something like this code,
rather than reinventing the wheel.

Things you need to watch out for are (a) leap seconds; (b) time zones.
I didn't really address the time zone problem, instead doing everything in
UTC.  For us Europeans, it doesn't normally make any difference whether
you use local or UTC time when you ask for the date one month from now.