In article
Have you read "Calendrical Calculations"? http://www.cup.cam.ac.uk/catalogue/catalogue.asp?isbn=0521777526
Yes, I highly recommend it. It discusses the relevant astronomy and background of each calendar and avoids the more common pitfalls in understanding calendars, such as equating the mean tropical year and the vernal equinox year. I have time this coming week (between work contracts) during which I hope to do some more work on TimeLib. There are two big changes I want to make. Speak now if you thing these are bad ideas: 1. Moving modules to Data.Time.* I believe this makes more sense because most of the library is calculation and only functions that obtain the current time and time zone use the system. We also avoid the existing System.Time so there's less confusion. This is not such a big change as far as authoring is concerned. 2. Unifying day types Right now ModJulianDay and the valid subset of GregorianDay (and other instances of DayEncoding) are isomorphic and represent the same thing. This leads to two problems: how to deal with invalid GregorianDays, and confusion arising from redundancy. I was doubtless influenced by C/C++, where a field accessor is "cheaper" in some sense than a function, and so having a separate "broken down" type makes sense. Haskell is different of course. I intend to have a single type to represent days, probably called Day or Date, which will be a newtype of Integer to represent the MJD number. There will be functions to obtain (year,month,day) values as well as construct from that (truncating to correct ranges). This will simplify the type system: the DayEncoding class with its confusingly-named members will be removed, DayAndTime and ZonedTime will no longer need a type parameter, and so on. Anyone wishing to create functionality for some other calendar (Hebrew, for instance), can just create functions without needing a new type. -- Ashley Yakeley, Seattle WA