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
