[Haskell-cafe] [Haskell] ANNOUNCE: time-recurrence-0.1
gale at sefer.org
Mon May 23 08:35:09 CEST 2011
Moving the discussion from haskell to haskell-cafe.
Chris Heller wrote:
>> A library for generating and inspecting recurring times.
Very nice. Please put it up on hackage so we can see the
haddocks, try it out easily, etc.
>> hoping to solicit some feedback on its design.
Very well done.
I have been think about recurrence rules, too. Version 2
Olson timezone files contain POSIX rules to specify
clock change rules for times later than the last one listed
in the timezone series. Currently, the timezone-series
package ignores those.
I like your introduction of symbolic months and weekdays.
The numeric-only interface of Data.Time for those things
leads to messiness like multiple functions depending on
how you number the weekdays. That logic should
be moved out to a separate interface.
You are correct that it is worth creating a separate module
for that. Please do so! Include neater versions of the
corresponding functions from Data.Time.
Another comment - I would have used fromGregorianValid
instead of fromGregorian. It's not a good idea for a basic time
library to introduce possible crashes. At least you should
provide an alternative safe interface. Similarly for toEnum.
>> The general direction is to have something that works much
>> like the RRULE portion of the iCalendar (RFC 5545)
>> specification. I have decided avoid strict RFC compliance
>> at this time.
Ashley Yakeley wrote:
> At one point I investigated a really generalised version of this, including
> an abstract syntax type and perhaps a way of parsing some useful
> subset of English expressions into it. However I got stuck on such
> things as
> "any day after the sixth Sunday of a month"
> In order to prove that today was not such a day, it would have know that
> "sixth Sunday of a month" never happens. Simply searching into the past for
> one would never terminate. Either I would have to restrict the language, or
> assert the beginning of time (not necessarily a bad solution).
I don't see why you would need to make any such restrictions.
There would only be a finite number of primitive comparison
types, and since your language would be total, any expression could
be reduced to the primitive ones in a finite number of steps. Then it
would just be a matter of arithmetic on sets of ranges; see, for
That allows for half-infinite and infinite ranges as well.
More information about the Haskell-Cafe