[Dev] ICU, datetimes, and recurrence
alecf at osafoundation.org
Mon Mar 28 07:32:06 PST 2005
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
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.
More information about the Dev