Keith Wansbrough wrote:
Rather than talk about specific Haskell code, I'd like to discuss the measurement of time in general, how these concepts might be expressed in Haskell, and what people might want from a time library. Rather than propose anything, I want to try to ask some of the right questions.
Wow, thanks for the impressive essay!
I second that -- it was a pleasant read and a very nice summary. Considering all the issues, it seems important to be pragmatic about the Time library: The first attempt at the Time library should probably focus on the basics that we clearly understand: TAI and UTC, and maybe time zones. The more tricky stuff, like calendars, and "next year" can than be dealt with later, on top of the well understood libraries. -- Daan.
I think we should also consider some of the things people might want to do with these times. In particular, people often want to compute with time differences: next week, next month, next year, etc. These are calendar operations, and defining precisely what they mean in edge cases is often tricky. Even discounting leap seconds and the like, "next month" is sometimes 28 days into the future, sometimes 29, sometimes 30, and sometimes 31 - and sometimes makes little sense: when is "31 January 2005 plus one month"? Similarly for "next year". And the decisions will be different for different applications - "plus one year" when computing a birthday or anniversary will be different from "plus one year" when computing interest on a loan.
Any "time difference" type must deal carefully with these issues, and must document its behaviour on the edge cases.
--KW 8-)
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries