[Haskell-cafe] [Haskell] ANNOUNCE: time-recurrence-0.1

[Yitzchak Gale]

Moving the discussion from haskell to haskell-cafe.

Chris Heller wrote:
>> http://github.com/hellertime/time-recurrence
>> 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
example, http://hackage.haskell.org/package/Ranged-sets
That allows for half-infinite and infinite ranges as well.

Regards,
Yitz