In article <20060206124958.GE4514@soi.city.ac.uk>,
Ross Paterson
On Mon, Feb 06, 2006 at 12:00:44AM -0800, Ashley Yakeley wrote:
Please take a look at my third draft of a replacement for the standard time library. http://semantic.org/TimeLib/
It looks very clean.
Thank you. This was a design goal.
One oddity I noted was that the Gregorian counterparts of the functions in Data.Time.Calendar.Julian are split between Data.Time.Calendar and Data.Time.Calendar.OrdinalDate, the latter having different names. Data.Time.Calendar.Gregorian? Then someone will want you to take Julian and Gregorian out of the function names, I suppose.
Julian calendar functions are likely to be rarely used, so I put that in a second-level module as part of my scheme to keep the common stuff in Data.Time.* and the less common stuff in Data.Time.*.*.
You might want to throw in Julian versions of the startWeek functions for completeness.
I may do this. I may also promote isLeapYear from .Calendar.OrdinalDate to .Calendar if it doesn't screw up the dependencies too much (.Calendar.Gregorian exists but is hidden: it depends on .Calendar.OrdinalDate). I suppose I could have isLeapYear in both.
There's also the question of replacing some tuples by records.
OK, currently we have this: toGregorian :: Day -> (Integer, Int, Int) fromGregorian :: Integer -> Int -> Int -> Day -- clips to ranges In version 0.1 I had a record type instead: data GregorianDay = MkGregorianDay { gregorianYear :: Integer, gregorianMonth :: Int, gregorianDay :: Day } This is a completely new type that is almost, but not quite, isomorphic to Day. As such, I made it an instance of most of the same classes as Day. It isn't quite isomorphic, however, since it allows invalid days, and these needed to be dealt with in all the code that used it. And it doesn't actually gain us anything. The useful parts of GregorianDay are the constructor and the access functions, not the type itself, and it's easier to do that with functions on Day. I had a class for types such as GregorianDay that were isomorphic to Day. It just confused people.
Might the Clock and LocalTime modules belong under System?
Not the whole modules, no, I'd rather keep the pure calculation under Data. There might be a case for putting the FFI-using functions under System (getCurrentTime, getPOSIXTime, getTimeZone, getCurrentTimeZone, getZonedTime, utcToLocalZonedTime) since they all call system functions, but we'd have to pick a module name. I'll only do it if a lot of people think it's a good idea, otherwise I'm happy with keeping everything under Data.Time. -- Ashley Yakeley, Seattle WA WWED? http://www.cs.utexas.edu/users/EWD/