RFC: Time Library 0.1

[Scott Turner]

Very nice library. Here are some comments.

How do I convert a DayAndTime to a CalendarTime in the local time zone? Due to 
summer time, the current time zone might be incorrect.

One aspect which adds difficulty to the library is that common concepts are 
supported using obscure types. For example, adding a number of days has an 
expression like
     encodeDay (decodeDay day +1)
which uses ModJulianDay, a representation most are unfamiliar with.
Similarly, absolute differences between times are provided by AbsoluteTime 
which is TAI. The way to calculate absolute time differences based on UTCTime 
is via an excursion to TAITime.  Modified Julian day and TAI give the library 
a solid foundation.  However, many users wouldn't expect that adding a number 
of days to a Gregorian date would entail encoding and decoding, and as a 
result would have difficulty finding/understanding how it's done.

Which is the code, 2005-07-11 or 53562? I try to answer that question whenever 
I use encodeDay or decodeDay. The time library's answer is counterintuitive. 
The names toModJulianDay and fromModJulianDay would be easier to deal with. 
Similarly for the other uses of encode/decode. Simon Marlow wrote:
> The question is, what's the result of encodeUTC for an invalid
> CalendarTime.
It's decodeUTC which takes a calendar time.  :-)

More friendly than the DayEncoding class would be a DayDiff class that 
provides addDays and diffDays. Similarly, I'd like to see a class that 
provides addTime and diffTime (however the attendant leap second issue is 
resolved).

UTCDiffTime, addUTCTime, and diffUTCTime intentionally ignore  
leap seconds. For example, diffUTCTime will return a 0 value for the 
duration of any event which occurs during a leap second. The "UTC" prefix 
poorly expresses the distinction between the two types of DiffTime, because 
UTC in comparison to POSIX time serves the opposite role. It's UTC which 
accounts for leap seconds so that correct absolute time differences can be 
recorded. NominalDiffTime, addNominalTime, and diffNominalTime would be 
better names than UTCDiffTime, etc.

> ISSUE: What kind of "Gregorian arithmetic" should I add, if any?
I'd like to see a way of representing Gregorian months, i.e. a partial time 
w/o day of year such as 2005-07.  Also a class providing addMonths and 
diffMonths. A `dayOfMonth` function would map Gregorian months to 
GregorianDays.
  lastOfTheMonth m = dayOfMonth (addMonths 1 m) 0