RFC: Time Library 0.1
pkeeken at students.cs.uu.nl
pkeeken at students.cs.uu.nl
Mon Jul 11 09:46:08 EDT 2005
i looked at the Time library, it looks really good and more complete than
the current ghc one and i am thinking of using it for a project. But i
only seem to miss a function for getting a week number from a calendar
ctWeek :: CalendarTime -> Int
or is there another way for doing it, i still dont completely get this
thing with ISOweek.
ps: having more documentation (with clear examples) would be great, which
should be the case with all (ghc) documentation! :)
> 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.
> 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. 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
> 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. 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
> 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
> 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.
> Ashley Yakeley, Seattle WA
> Libraries mailing list
> Libraries at haskell.org
More information about the Libraries