Time Library Date Normalisation and Arithmetic

[Ashley Yakeley]

In article <Pine.LNX.4.60.0507261531030.24946 at hermes-1.csi.cam.ac.uk>,
 Tony Finch <dot at dotat.at> wrote:

> 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