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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
