[Dev] ICU, datetimes, and recurrence

[Alec Flett]

Jeffrey Harris wrote:

>- We can't represent indefinitely recurring events in the repository,
>currently the only way to create a recurring event is to import it from
>iCalendar, and then only the first 10 events are put in the repository
>to avoid infinite loops
>  
>
I think this is actually the hardest problem we're facing in chandler, 
probably due for its own thread.

I second your motion to use ICU date/time stuff, but knowing nothing 
more about it I'm hoping Nick can at least give us a little information 
about the bindings -i.e. the maturity of the the bindings today vs. 
mx.DateTime. Nick, do you have any sort of page describing your 
progress, or work we can download and maybe contribute to right now?

I have no desire for us to write our own recurrence library, so I also 
like the use of dateutil.rrule. Let's just agree that's what we're using 
sans any massive technical hurdles. I've looked around and I can't find 
any info on rrule though - is there a web page out there for it? I guess 
I'm curious what requirements it has, and what the interface is like...
I think we have two options. The decision is probably a technical one, 
and Jeffrey I think you're the expert here..
- we can contribute back support for ICU to dateutil.rrule- if rrule 
isn't heavily bound to datetime (though I suspect it is...)
- create our own wrapper or glue code around rrule so that we can easily 
translate the two.

I suspect we'll have to do the latter since we're also bound up by 
mx.DateTime constraints at the moment.

In any case, I want to be able to use dateutil.rrule or chandler.rrule 
as if it is the real rrule, but dealing with ICU dates. Same API, etc, 
so that if rrule ever adds support for ICU, we can keep getting and 
using updates.

If ICU datetime is really where we want to go, we should probably at 
least discuss and document a migration path for all of chandler, if only 
to help us understand the reasons and scope of the migration. I don't 
think it has to be a single monotonic conversion though.

Alec