Parsing date and time specifications

[Simon Marlow]

> I think it is widely agreed that the time and date structures in the
> standard libraries are brok^H^H^H^Hslightly less than useful.
>=20
> I suggest you feel free to rewrite it as you see fit, and then lobby
> for its inclusion in the hierarchical libraries.=20
>=20
> (My preju^H^Hference would be to store a date-time internally in a
> posix-like manner (seconds,microsecond since the epoch).)

But a ClockTime *is* implemented as (seconds,picoseconds) since the
epoch.  CalendarTime is just a human-readable interpretation of the
ClockTime, or a way to synthesise a ClockTime from a known date/time.

(BTW Peter: the weekday/yearday in a CalendarTime are ignored by the
toClockTime in GHC's Time library, so you can set them to anything).

I'm still not sure I understand why the Time library is considered to be
broken; sure I can see that our implementation of addToClockTime is
wrong (adding one minute shouldn't always be the same as adding 60
seconds, for example), but is the design fundamentally wrong?

GHC's TimeExts library (package lang) is allegedly a better
implementation of addToClockTime/diffClockTime, if anyone is looking for
one.

Cheers,
	Simon