---- Reported by karlrt@gmx.net 2010-11-16 14:49:26 +0000 ----

Created attachment 3534 [details]
with this file, SE wont use the repeat-values

BUILD IMAGE: 1.1-2         

HARDWARE MODEL (on what HW this bug is uncovered): Sony Ericsson t700 in sync
with ubuntu 10.10 on thinkpad t61

BUG DETAILED DESCRIPTIONS
===========================================================

EXACT STEPS LEADING TO PROBLEM:
(Explain in detail what you do (e.g. tap on OK) and what you see (e.g. message
Connection Failed appears))
===========================================================
1.make a repeated event without a repeat end (see attachment)
2.sync it with mobilephone --> SE sees it as a repeated event
3.make a repeated event with an end
4.sync it with mobilephone
5.Not one repeat is shown

EXPECTED OUTCOME:
===================

SE should show repeated alarms also with an "until" value assigned

ACTUAL OUTCOME:
===================

SE doesnt show any repeated events, just the root-event

USER IMPACT:
===================

Cannot use repeated events for my sync

REPRODUCIBILITY:
(always, less than 1/10, 5/10, 9/10)
=====================================

EXTRA SOFTWARE INSTALLED:
============================

OTHER COMMENTS:
===================



---- Additional Comments From karlrt@gmx.net 2010-11-16 14:50:04 +0000 ----

Created attachment 3535 [details]
with this file, SE works fine



---- Additional Comments From karlrt@gmx.net 2010-11-16 14:53:31 +0000 ----

Created attachment 3536 [details]
this file has exeption-rules specified, evolution uses them, SE ignores them



---- Additional Comments From patrick.ohly@intel.com 2010-11-16 23:38:21 +0000 ----

Not sure how to work around this. One possibility would be to remove the end date before sending to the phone, but that changes the semantic of the event.

Do events with a repeat count ("repeat for x occurrences" instead of "repeat until xyz") work with the phone? That might be a better workaround.



---- Additional Comments From karlrt@gmx.net 2010-11-17 04:53:33 +0000 ----

(In reply to comment #3)
> Not sure how to work around this. One possibility would be to remove the end
> date before sending to the phone, but that changes the semantic of the event.

i agree, this is not the right way to handle it

> Do events with a repeat count ("repeat for x occurrences" instead of "repeat
> until xyz") work with the phone? That might be a better workaround.  

Yes, they work:

While RRULE:FREQ=DAILY;COUNT=4 does the job, RRULE:FREQ=DAILY;UNTIL=20101120 only shows the first event on the phone.

Also ignored by sony ericsson are the excluded dates of an event, e.g. EXDATE;VALUE=DATE:20101119

should this be treated as a different issue (bug report?)



---- Additional Comments From patrick.ohly@intel.com 2010-11-17 05:35:51 +0000 ----

(In reply to comment #4)
> (In reply to comment #3)
> > Do events with a repeat count ("repeat for x occurrences" instead of "repeat
> > until xyz") work with the phone? That might be a better workaround.  
> 
> Yes, they work:
> 
> While RRULE:FREQ=DAILY;COUNT=4 does the job, RRULE:FREQ=DAILY;UNTIL=20101120
> only shows the first event on the phone.

Okay, so this might be a valid workaround. Now I just need to figure out how to count the number of recurrences until the end date :-/

I'm assigning to me, but if anyone has a bright idea, feel free to take over.

> Also ignored by sony ericsson are the excluded dates of an event, e.g.
> EXDATE;VALUE=DATE:20101119
> 
> should this be treated as a different issue (bug report?)  

Yes, please. Questions to answer there: does the phone support such exceptions? How? This can be tested by creating a repeating event on the phone, then deleting one recurrence - if the UI allows that. When you sync, use loglevel=4 (if you haven't already) to find the item that the phone sends. Please include in that new issue.



---- Additional Comments From patrick.ohly@intel.com 2010-12-13 07:50:17 +0000 ----

(In reply to comment #4)
> (In reply to comment #3)
> > Not sure how to work around this. One possibility would be to remove the end
> > date before sending to the phone, but that changes the semantic of the event.
> 
> i agree, this is not the right way to handle it
> 
> > Do events with a repeat count ("repeat for x occurrences" instead of "repeat
> > until xyz") work with the phone? That might be a better workaround.  
> 
> Yes, they work:
> 
> While RRULE:FREQ=DAILY;COUNT=4 does the job, RRULE:FREQ=DAILY;UNTIL=20101120
> only shows the first event on the phone.

I think I fixed this issue as part of https://bugs.meego.com/show_bug.cgi?id=11241, without realizing it at first. The root cause of #11241 is that UNTIL=20101120 in iCalendar 2.0 leads to an invalid RRULE being sent in the vCalendar 1.0 item. COUNT=4 takes a slightly different code path and ends up sending a valid RRULE (https://bugs.meego.com/show_bug.cgi?id=11241 comment #1).

Can you try this with the SyncEvolution 1.1.0.99.1 that I am going to release this week? I'll announce it on mailing list.



---- Additional Comments From karlrt@gmx.net 2010-12-13 08:12:51 +0000 ----

> Can you try this with the SyncEvolution 1.1.0.99.1 that I am going to release
> this week? I'll announce it on mailing list.  

sounds great, i will try with new release



---- Additional Comments From patrick.ohly@intel.com 2010-12-21 12:04:11 +0000 ----

(In reply to comment #7)
> > Can you try this with the SyncEvolution 1.1.0.99.1 that I am going to release
> > this week? I'll announce it on mailing list.  
> 
> sounds great, i will try with new release  

1.1.0.99.1 is available on syncevolution.org (unstable .deb repos, download area).



---- Additional Comments From karlrt@gmx.net 2010-12-22 02:27:03 +0000 ----

its partly fixed, but somewhere while converting the bug, it adds one day on my phone.

it converts now from:

BEGIN:VCALENDAR
PRODID:-//Ximian//NONSGML Evolution Calendar//EN
VERSION:2.0
METHOD:PUBLISH
BEGIN:VTIMEZONE
TZID:/freeassociation.sourceforge.net/Tzfile/Europe/Vienna
X-LIC-LOCATION:Europe/Vienna
BEGIN:STANDARD
TZNAME:CET
DTSTART:19701031T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
TZNAME:CEST
DTSTART:19700328T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:20101222T101547Z-4698-1000-1-72@ThinkPad-T61
DTSTAMP:20101222T101547Z
DTSTART;TZID=/freeassociation.sourceforge.net/Tzfile/Europe/Vienna:
 20101223T080000
DTEND;TZID=/freeassociation.sourceforge.net/Tzfile/Europe/Vienna:
 20101223T083000
TRANSP:OPAQUE
SEQUENCE:2
SUMMARY:test until 26
CLASS:PUBLIC
RRULE:FREQ=DAILY;UNTIL=20101226
CREATED:20101222T101611Z
LAST-MODIFIED:20101222T101611Z
BEGIN:VALARM
X-EVOLUTION-ALARM-UID:20101222T101611Z-6634-1000-1-112@ThinkPad-T61
DESCRIPTION:test until 26
ACTION:DISPLAY
TRIGGER;VALUE=DURATION;RELATED=START:-PT1H
END:VALARM
END:VEVENT
END:VCALENDAR

To:

BEGIN:VCALENDAR
VERSION:1.0
BEGIN:VEVENT
DTSTART:20101223T070000Z
DTEND:20101223T073000Z
DESCRIPTION:test until 26
SUMMARY:test until 26
RRULE:D1 20101226T235959
DALARM:20101223T060000Z
AALARM:20101223T060000Z
LAST-MODIFIED:20101222T101639Z
X-SONYERICSSON-DST:0
X-IRMC-LUID:000000000175
END:VEVENT
END:VCALENDAR

While the phone has set the rule to RRULE:D1 20101226T235959 it still shows me one event on the 27th, so one day to long. This might be because of 235959 with some timezone conversion might be in the next day? but this is just a wild guess!



---- Additional Comments From patrick.ohly@intel.com 2010-12-26 05:28:45 +0000 ----

(In reply to comment #9)
> its partly fixed, but somewhere while converting the bug, it adds one day on my
> phone.
[...]
> While the phone has set the rule to RRULE:D1 20101226T235959 it still shows me
> one event on the 27th, so one day to long. This might be because of 235959 with
> some timezone conversion might be in the next day? but this is just a wild
> guess!  

Sounds plausible to me.

I tried your test case with a Nokia N97, which showed the event the last time on the 26th, as it should be. So what we need is a better heuristic or a Sony Ericsson specific conversion.

What is the timezone on your phone? Also European time, I suppose?

How does the phone send events which have end dates? Please quote an example which ends in the summer and one which ends in the winter - I wonder whether summer saving time has an effect.

I think I'll go ahead with the 1.1.1 release and keep solving this issue for later.



---- Additional Comments From karlrt@gmx.net 2010-12-26 06:06:20 +0000 ----

(In reply to comment #10)
> What is the timezone on your phone? Also European time, I suppose?

Yes, GMT+1

> How does the phone send events which have end dates? Please quote an example
> which ends in the summer and one which ends in the winter - I wonder whether
> summer saving time has an effect.

There seems to be no difference. Heres the rules for a reoccuring event, with end-date as it comes from the phone. The event is from 15-15.30 GMT+1, in the file its all UTC:

summer:
RRULE:D1 20100728T143000Z
winter:
RRULE:D1 20101228T143000Z

> I think I'll go ahead with the 1.1.1 release

good



---- Additional Comments From patrick.ohly@intel.com 2011-01-05 07:05:30 +0000 ----

See also the "[SyncEvolution] Recurring events created on Nokia E63 become duplicated on Evolution" mail thread", which shows a situation where the end date is not correctly handled for the E63->Evolution direction.



---- Additional Comments From patrick.ohly@intel.com 2011-10-26 14:21:28 +0000 ----

I've made some more changes to the UNTIL clause conversion which will land in SyncEvolution 1.3. They were made to better align the content of the UNTIL clause with the DTSTART type (all-day, date-time).

Perhaps that changed the behavior in combination with the Sony Ericsson.

karlrt, is this still relevant for you? Want to test?



--- Bug imported by patrick.ohly@gmx.de 2012-07-29 20:36 UTC  ---

This bug was previously known as _bug_ 10092 at https://bugs.meego.com/show_bug.cgi?id=10092
Imported an attachment (id=64921)
Imported an attachment (id=64922)
Imported an attachment (id=64923)