<JJ (Jason)>I went for the Recurrence rule standard which is ugly, ambiguous and, though my test coverage didn't point anything out, I think even self-contradicting.</JJ (Jason)>
Yes. And others have said the same thing. One of the things I want to check is your interpretation of iCal versus mine. And versus that of others.
One of the issues I'm dealing with is to ensure that the Chronos rule model can represent any of the possible interpretations of an iCal ruleset, so that the ambiguity issue will be the sole responsibility of the iCal parser.
And of course, I have to ensure that recurrence rules using non-Gregorian calendars also work correctly--something iCal currently doesn't address.
<JJ (Jason)>I learned a lot in the doing.</JJ (Jason)>
I'm sure you did. So did I. Chronos itself, and recurrence rules in particular, have proved to be far more complex and challenging than I had anticipated before I really got into them. The date/time functional domain is not easy, not trivial, not simple, and cannot be adequately handled (let alone comprehensively handled) with only a handful of classes and methods. Collections and Streams are easy by comparison.
<JJ (Jason)>I don't know how much of my stuff will be usable for you.</JJ (Jason)>
I am intrigued by your approach using LazyLists. Since Chronos' recurrence rules are implemented as executable syntax trees, it should be possible to use them to emit ("compile") rules into your rule engine.
--Alan