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