RFC: Time Library 0.3

[Ashley Yakeley]

In article <20060206124958.GE4514 at soi.city.ac.uk>,
 Ross Paterson <ross at soi.city.ac.uk> wrote:

> 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/