On Wed, 2010-09-08 at 14:29 +0100, Álvaro Manera wrote:
> On Wednesday 08 September 2010 15:41:31 ext Patrick Ohly wrote:
> > On Wed, 2010-09-08 at 13:29 +0100, Álvaro Manera wrote:
> > > > Calendar
> > > > ========
> >
> > [...]
> >
> > > > It seems that RECURRENCE-ID is stored in Tracker, but only after
> > > > conversion to UTC and without milliseconds:
> > > > // The format supported by tracker is not really ISO8601, as it
> > > > // doesn't support milliseconds. Therefore we eliminate those here.
> > > > QString kdatetime2String( KDateTime dt, bool toUtc=true )
> > > >
> > > > Question: ignoring the problem with milliseconds here (doesn't matter
> > > > for iCalendar 2.0), can mkcal find the original incidence when it has a
> > > > RECURRENCE-ID using a time zone and the query uses UTC?
> > >
> > > mkcal doesn't need to open tracker, at least not at the moment. mkcal is
> > > just pushing contect to it.
> >
> > I was thinking of the other direction: find something in Tracker,
> open
> > it in mkcal. Is that possible?
> >
>
> It is "possible". But the logic it is in the application using mkcal. So you
> get the uri from tracker (the way you want) parse it, if it is only Id you
> can
> load it from mkcal if not, take the recurrenceId and open it.
How do you suggest that the app logic solves the problem that I
mentioned above (reconstruct recurrenceId)? In particular the last part
with "take the recurrenceId"? You haven't commented whether passing a
KDateTime with UTC will be good enough to find an event which is not in
UTC.
I started to write an example program illustrating the issue, but ran
into multiple other problems (issues filed):
1. no valid time zone definitions found: BMC #6438
2. Tracker doesn't seem to be used at all: BMC #6439
Perhaps I misunderstand how the Tracker integration works, but let's
discuss that in BMC #6439.
So here's an ID as I expect to be used with Tracker, without being able
to verify this:
UID: 463fae7b-f688-444c-9a0f-e3dda42f2adb
RECURRENCE-ID;TZID=Europe/Berlin:20100908T120000
=>
Tracker ID: 463fae7b-f688-444c-9a0f-e3dda42f2adb-2010-09-08T10:00:00Z
Correct?
Splitting into UID and RECURRENCE-ID is possible, but there is no
information about the original time zone. So at best, a KDateTime can be
constructed with:
QString uid = "463fae7b-f688-444c-9a0f-e3dda42f2adb";
KDateTime rid = KDateTime::fromString("2010-09-08T10:00:00Z");
storage->load(uid, rid);
calendar->incidence(uid, rid);
Is that going to work?
Note that this is roughly what SyncEvolution does, but I have not been
able to determine whether it is correct in the presence of time zones
because of the open issues (BMC #6054). It also still fails randomly in
my tests (BMC #6061).
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
