<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: SyncEvolution + ScheduleWorld + Calendar Synchronization: iCalendar 2.0, but&#8230;</title>
	<atom:link href="http://www.estamos.de/blog/2007/11/22/syncevolution-scheduleworld-calendar-synchronization-icalendar-20-but/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.estamos.de/blog/2007/11/22/syncevolution-scheduleworld-calendar-synchronization-icalendar-20-but/</link>
	<description>About SyncEvolution, writing software and more.</description>
	<lastBuildDate>Sun, 04 Jul 2010 13:39:24 +0200</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.1-beta1</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Mark Swanson</title>
		<link>http://www.estamos.de/blog/2007/11/22/syncevolution-scheduleworld-calendar-synchronization-icalendar-20-but/comment-page-1/#comment-541</link>
		<dc:creator>Mark Swanson</dc:creator>
		<pubDate>Thu, 20 Dec 2007 05:19:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.estamos.de/blog/2007/11/22/syncevolution-scheduleworld-calendar-synchronization-icalendar-20-but/#comment-541</guid>
		<description>I was wrong. The use case does change. Sorry about that.

Cheers.</description>
		<content:encoded><![CDATA[<p>I was wrong. The use case does change. Sorry about that.</p>
<p>Cheers.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Patrick Ohly</title>
		<link>http://www.estamos.de/blog/2007/11/22/syncevolution-scheduleworld-calendar-synchronization-icalendar-20-but/comment-page-1/#comment-530</link>
		<dc:creator>Patrick Ohly</dc:creator>
		<pubDate>Wed, 19 Dec 2007 21:45:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.estamos.de/blog/2007/11/22/syncevolution-scheduleworld-calendar-synchronization-icalendar-20-but/#comment-530</guid>
		<description>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.</description>
		<content:encoded><![CDATA[<p>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.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark Swanson</title>
		<link>http://www.estamos.de/blog/2007/11/22/syncevolution-scheduleworld-calendar-synchronization-icalendar-20-but/comment-page-1/#comment-496</link>
		<dc:creator>Mark Swanson</dc:creator>
		<pubDate>Tue, 18 Dec 2007 20:22:03 +0000</pubDate>
		<guid isPermaLink="false">http://www.estamos.de/blog/2007/11/22/syncevolution-scheduleworld-calendar-synchronization-icalendar-20-but/#comment-496</guid>
		<description>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&#039;m not emailed when updates are made to this blog and I likely won&#039;t see your response if you post here.

Cheers.</description>
		<content:encoded><![CDATA[<p>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&#8217;m not emailed when updates are made to this blog and I likely won&#8217;t see your response if you post here.</p>
<p>Cheers.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Patrick Ohly</title>
		<link>http://www.estamos.de/blog/2007/11/22/syncevolution-scheduleworld-calendar-synchronization-icalendar-20-but/comment-page-1/#comment-452</link>
		<dc:creator>Patrick Ohly</dc:creator>
		<pubDate>Sun, 16 Dec 2007 15:58:37 +0000</pubDate>
		<guid isPermaLink="false">http://www.estamos.de/blog/2007/11/22/syncevolution-scheduleworld-calendar-synchronization-icalendar-20-but/#comment-452</guid>
		<description>Some more experiments... I did a &quot;refresh-from-client&quot; 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 &quot;refresh-from-server&quot;. 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 &quot;once per month&quot; 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&#039;t claim to know who is right or wrong here because I haven&#039;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.</description>
		<content:encoded><![CDATA[<p>Some more experiments&#8230; I did a &#8220;refresh-from-client&#8221; 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.</p>
<p>Then I did a &#8220;refresh-from-server&#8221;. 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.</p>
<p>After sending the two events to Outlook they are both not recognized as recurring, perhaps because of the &#8220;once per month&#8221; 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.</p>
<p>I don&#8217;t claim to know who is right or wrong here because I haven&#8217;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&#8230;</p>
<p>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.</p>
<p>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.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Patrick Ohly</title>
		<link>http://www.estamos.de/blog/2007/11/22/syncevolution-scheduleworld-calendar-synchronization-icalendar-20-but/comment-page-1/#comment-448</link>
		<dc:creator>Patrick Ohly</dc:creator>
		<pubDate>Sun, 16 Dec 2007 09:52:15 +0000</pubDate>
		<guid isPermaLink="false">http://www.estamos.de/blog/2007/11/22/syncevolution-scheduleworld-calendar-synchronization-icalendar-20-but/#comment-448</guid>
		<description>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.</description>
		<content:encoded><![CDATA[<p>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.</p>
<p>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.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark Swanson</title>
		<link>http://www.estamos.de/blog/2007/11/22/syncevolution-scheduleworld-calendar-synchronization-icalendar-20-but/comment-page-1/#comment-445</link>
		<dc:creator>Mark Swanson</dc:creator>
		<pubDate>Sun, 16 Dec 2007 05:36:53 +0000</pubDate>
		<guid isPermaLink="false">http://www.estamos.de/blog/2007/11/22/syncevolution-scheduleworld-calendar-synchronization-icalendar-20-but/#comment-445</guid>
		<description>Your analysis isn&#039;t correct. There is no UTC issue like you describe. The previous behaviour and the new behaviour are identical wrt your use case.</description>
		<content:encoded><![CDATA[<p>Your analysis isn&#8217;t correct. There is no UTC issue like you describe. The previous behaviour and the new behaviour are identical wrt your use case.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

