Skip to content

SyncEvolution + ScheduleWorld + Calendar Synchronization: iCalendar 2.0, but…

As I just wrote about Funambol’s iCalendar 2.0 support I might as well add a report about a recent development in that regard with ScheduleWorld: ScheduleWorld has had full support for iCalendar 2.0 for a long time. Recently the nightly testing showed a difference in the server’s behavior which IMHO could potentially affect users.

In contrast to previous releases, ScheduleWorld now adds a time zone to recurring events which are explicitly specified to be relative to UTC. Such events are not the default in Evolution and one has to question the usefulness (is anyone tracking recurring events which do not follow daylight saving rules of a certain country – stargazing perhaps?), but it is possible in the GUI. In my opinion this data modification changes the event: for example, an event at 8:00UTC occurs at 9:00 German time in the winter and at 10:00 in the summer, but after it has been transformed to German time by ScheduleWorld it always occurs at 9:00 or 10:00. ScheduleWorld uses the account time zone and although I haven’t tested it, I suppose whether it’s 9:00 or 10:00 depends on summer saving status at the time when the transformation is applied.

I have discussed this with Mark and he has reasons to do it this way, but there was no time to explain them in detail. For the nightly testing he reverted the change, but not for other accounts, so beware if you have events in UTC. Now back to more important stuff…

[Update 2007-12-16] Here is the recurring event mentioned in the comments. How is it handled in your favorite calendar application?

{ 6 } Comments

  1. Mark Swanson | December 16, 2007 at 6:36 am | Permalink

    Your analysis isn’t correct. There is no UTC issue like you describe. The previous behaviour and the new behaviour are identical wrt your use case.

  2. Patrick Ohly | December 16, 2007 at 10:52 am | Permalink

    Mark, to verify my analysis I have created two recurring events in Evolution: both start on January 1st 2008, but one uses 9:00am German time and the other 8:00am UTC. During winter time both appear at 9:00am in my calendar (which uses German time). In the months with summer saving time the UTC event is displayed at 10:00am while the other one continues to recur at 9:00am.

    This behavior in Evolution is consistent with my intuitive understanding of recurrence. Of course, intuition might not be aligned with the iCalendar 2.0 specification. If you think that the developers of Evolution (or rather, libical) implement recurrence of UTC events incorrectly, then please explain where my analysis is faulty (Is it wrong regarding UTC recurrence? With regard to SW modifying a recurring event in UTC?) and back up your opinion with arguments.

  3. Patrick Ohly | December 16, 2007 at 4:58 pm | Permalink

    Some more experiments… I did a “refresh-from-client” sync of my calendar to ScheduleWorld. Both events are displayed in the ScheduleWorld web interface for July as occurring at the same time, which is not how Evolution displays them.

    Then I did a “refresh-from-server”. Now Evolution also shows them as occurring at the same time during the summer because the UTC event was stored with modified time stamps on ScheduleWorld and sent back in that modified format.

    After sending the two events to Outlook they are both not recognized as recurring, perhaps because of the “once per month” recurrence. I tried again with weekly recurrence and now I see that Outlook displays the UTC meeting as occurring at the same time (9:0am German time) throughout the year, just like ScheduleWorld does.

    I don’t claim to know who is right or wrong here because I haven’t read the iCalendar 2.0 RFC (yet). If someone has an educated opinion and pointers to the standard where the right behavior is defined, please chime in…

    For everyone else: I will attach the recurring meeting to the blog post. Please import it into your favorite calendar application and describe how it is handled in a comment. That way we will at least learn how different applications interpret the iCalendar 2.0 standard.

    I tried it with KDE korganizer 3.5.8. It also displays the recurring UTC event as occuring on the same time of day throughout the year, but in contrast to ScheduleWorld exporting the event again leaves the event unchanged, i.e. with absolute UTC time stamps.

  4. Mark Swanson | December 18, 2007 at 9:22 pm | Permalink

    Good job testing with Outlook and KOrganizer too. If anyone can think of a reason why a weekly 10AM meeting should change by an hour after a timezone change (from one week to the next) please post to the ScheduleWorld forums as I’m not emailed when updates are made to this blog and I likely won’t see your response if you post here.


  5. Patrick Ohly | December 19, 2007 at 10:45 pm | Permalink

    I also tested the UTC event in Apple iCal: iCal shows the event the same way as Evolution, i.e. at 9am during the winter and at 10am during the summer.

  6. Mark Swanson | December 20, 2007 at 6:19 am | Permalink

    I was wrong. The use case does change. Sorry about that.


Post a Comment

Your email is never published nor shared. Required fields are marked *