Time Library 0.1

[Simon Marlow]

I just had a little look around, mainly at System.Time.Calendar.  I
think the structure is rather complicated - I wanted to find out how to
get a CalendarTime for "this time tomorrow", and ended up with this:

*System.Time.Calendar> let c' =
c{ztTime=zttime{dtDay=dtday{gregDay=day+1}}} where { zttime = ztTime c;
dtday = dtDay zttime; day = gregDay dtday }

and I found that CalendarTime isn't normalised, you have to convert to
UTCTime and then back again to get normalisation (does that do proper
normalisation?).  Perhaps we should have normaliseCalendarTime.

It would be useful to provide this:

   utcToLocalCalendarTime :: UTCTime -> IO CalendarTime

(encodeLocalUTC is taken).

I guess the main problem is the difficulty of working with CalendarTime
due to the complicated type structure in this module.  We should aim to
make it easy to do common manipulations of CalendarTime (such as those
suggested by Brian Smith).

Cheers,
	Simon

On 05 July 2005 09:23, Ashley Yakeley wrote:

> Sorry for the hiatus, my job has left less free time to work on this.
> 
> Please take a look at a first attempt at writing a replacement for the
> standard time library.
> http://semantic.org/TimeLib/
> 
> Take a look at the Haddock documentation:
> http://semantic.org/TimeLib/doc/html/
> 
> Download the source:
> http://semantic.org/TimeLib/TimeLib-0.1.tar.gz
> 
> Or keep up-to-date:
> darcs get http://semantic.org/TimeLib/TimeLib/
> 
> It needs GHC 6.4. Just run "make" to build the library, tests and
> documentation. There's also a cabal file (as a completely separate
> build process), but I've been having trouble with that on Mac OS X.
> 
> I'm particularly interested in comments from people who try to write
> little applications for it. What did you have trouble with? What made
> no sense?
> 
> Some points:
> 
> 1. There is no leap second table provided, though there is a type
> (LeapSecondTable) for such things. Any software compiled with a fixed
> table would soon become out of date.
> 
> 2. There is no table of time-zones provided, since these also change.
> However, if there's a good way of getting this from the TZ database on
> the machine, I'll add that.
> 
> It is actually possible to get the local time-zone for any given time,
> indeed one of the test programs finds your local summertime
> transitions. The Timezone type includes name, minutes of offset, and
> a "summertime" flag.
> 
> 3. I allow multiple calendars with the DayEncoding class. GregorianDay
> is the most obvious instance, but there are some other useful ones
> such as ISOWeek. And anyone interested in local cultural calendars
> can plug their own in here.
> 
> 4. The TimeLocale type comes from the already existing System.Locale.
> 
> 5. I've tried to balance simplicity and functionality. Of course, the
> majority of people will only be interested in ordinary Gregorian date
> and time, so I have a simple CalendarTime type synonym with associated
> functions:
> http://semantic.org/TimeLib/doc/html/System.Time.Calendar.html#8
> 
> 6. It's not possible to expunge POSIX time. I've hidden it, but it's
> used behind the scenes. Why? Because it's the only way to do sensible
> arithmetic on UTC times without knowing the leap second table and
> without worrying about one-second offsets.
> 
> 7. I include Data.Fixed which provides a fixed-point arithmetic type
> (wrapper around Integer). It probably should be in a separate package.
> It allows dealing with seconds as a single thing, rather than as an
> integer/picoseconds pair.
> 
> 8. I don't have any text-parsing functionality. This is a fair amount
> of work, so it would be good to know sensible requirements.