RFC: Time Library 0.2

Ashley Yakeley ashley at semantic.org
Mon Oct 31 02:04:12 EST 2005

Just in time for HCAR...

Please take a look at my second attempt at writing a replacement for the 
standard time library.

Take a look at the Haddock documentation:

Download the source:

Or keep up-to-date:
darcs get http://semantic.org/TimeLib/TimeLib/

It needs GHC 6.4.1. (I haven't tested with 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? Also have a look at some use-cases, which get compiled as part of 
the package tests:

Major changes since 0.1:

* Moved to Data.Time, since the actual "System" part (getting the 
current time and time-zone) is relatively small.

* Big simplification of types. Now tuples are used for calendar data 
(such as (year,month,day) for the Gregorian calendar), and the confusing 
DayEncoding class has been dropped.

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" 

3. The TimeLocale type comes from the already existing System.Locale.

4. It's not possible to expunge POSIX time. 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.

5. 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.

6. I don't have any text-parsing functionality for times. This is a fair 
amount of work, so it would be good to know sensible requirements.

7. Time as measured by the CPU since system startup remains in 
System.CPUTime, which TimeLib does not intend to replace.

Ashley Yakeley, Seattle WA

More information about the Libraries mailing list