On Fri, 2013-05-31 at 09:09 +0200, Vidar Evenrud Seeberg wrote: > Den 05/30/2013 11:49 PM, skrev David Woodhouse: > > DTSTART:20130602T180000 > > DTEND:20130602T190000 > > Hm, that's odd. Shouldn't those end with a 'Z' to indicate that they are > > in GMT? Then they'd be correct, right? The meeting was actually at 18:00 > > GMT? > No. The meeting was at 20:00 (look at summary: Test20)
Remember, times are meaningless without timezones. You should *always* specify the timezone unless it's completely obvious. The meeting was at 20:00 in *what* time zone? I thought it was at 20:00 in your local time zone, GMT+2. Which makes it 18:00 GMT? > > I'd like to see what we actually got back from the Exchange server for > > this event — can you show the XML you see in the calendar-factory > > output? From <t:CalendarItem> to </t:CalendarItem>. > Actually, the output seems encoded in some way, so I do not know which > calendar item is the correct. They're base64-encoded. Here's the first one, which I think is the interesting one: BEGIN:VCALENDAR METHOD:PUBLISH PRODID:Microsoft Exchange Server 2010 VERSION:2.0 BEGIN:VTIMEZONE TZID:W. Europe Standard Time BEGIN:STANDARD DTSTART:16010101T030000 TZOFFSETFROM:+0200 TZOFFSETTO:+0100 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10 END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T020000 TZOFFSETFROM:+0100 TZOFFSETTO:+0200 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3 END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT ORGANIZER;CN=Vidar Seeberg:MAILTO:vidar.seeb...@norsvin.no SUMMARY;LANGUAGE=en-US:Test entered for 20-21 DTSTART;TZID=W. Europe Standard Time:20130602T200000 DTEND;TZID=W. Europe Standard Time:20130602T210000 UID:1fe056fd367849478ebb324bd2fb0260 CLASS:PUBLIC PRIORITY:5 DTSTAMP:20130531T064042Z TRANSP:OPAQUE STATUS:CONFIRMED SEQUENCE:0 X-MICROSOFT-CDO-APPT-SEQUENCE:0 X-MICROSOFT-CDO-OWNERAPPTID:2111176071 X-MICROSOFT-CDO-BUSYSTATUS:BUSY X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-CDO-ALLDAYEVENT:FALSE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-INSTTYPE:0 X-MICROSOFT-DISALLOW-COUNTER:FALSE END:VEVENT END:VCALENDAR > However, some CalendarItems have timezone and some have not. Right. As I explained, you don't *need* to preserve the timezone for a non-recurring meeting. As long as the time is correct, it doesn't matter. It's quite normal to discard the original timezone and just remember the actual time of the meeting in UTC. > This is another ics for a test for a meeting at 20:00 to 21:00 entered > on the phone (exported from Evolution): > BEGIN:VCALENDAR > PRODID:-//Ximian//NONSGML Evolution Calendar//EN > VERSION:2.0 > METHOD:PUBLISH > BEGIN:VEVENT > SUMMARY;LANGUAGE=en-US:Test entered for 20-21 > DTSTART:20130602T180000 > DTEND:20130602T190000 > UID:1fe056fd367849478ebb324bd2fb0260 > CLASS:PUBLIC > PRIORITY:5 > DTSTAMP:20130531T064042Z > TRANSP:OPAQUE > STATUS:CONFIRMED > SEQUENCE:0 > X-MICROSOFT-CDO-APPT-SEQUENCE:0 > X-MICROSOFT-CDO-OWNERAPPTID:2111176071 > X-MICROSOFT-CDO-BUSYSTATUS:BUSY > X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY > X-MICROSOFT-CDO-ALLDAYEVENT:FALSE > X-MICROSOFT-CDO-IMPORTANCE:1 > X-MICROSOFT-CDO-INSTTYPE:0 > X-MICROSOFT-DISALLOW-COUNTER:FALSE > X-EVOLUTION-ITEMID: > AAMkADFmODk4OWM3LThkZTYtNDNiNy04MDI3LWE2MDFiNjEwMTVlZQBGAAAAAABfPsKLxmAeTq > GBhPnLcSToBwDpmmDdm/HZQbnuhOn4fMvuAAABV6JlAADZpHxTQYzrRJ5/zjxxNiNuAAAAKCiF > AAA= > X-EVOLUTION-CHANGEKEY:DwAAABYAAADZpHxTQYzrRJ5/zjxxNiNuAAAAKvG3 > END:VEVENT > END:VCALENDAR OK, so we can compare this with what Exchange actually gave us, which I showed above. Exchange *did* give us a full timezone definition for "W. Europe Standard Time", and then defined the meeting as 20:00-21:00 in that time zone. It looks like Evolution converted to UTC (18:00-19:00) but failed to correctly represent that. It's stored it as a "floating time", as Milan said. Floating times (where the timezone isn't fixed, and it's 18:00 in whatever time zone the viewer happens to be in at the moment), are fairly much useless for any event other than "hey, the sun is overhead". This might have happened because we don't usually expect Exchange to give us non-recurring meetings in any timezone *other* than UTC, so this code path isn't well-tested? > This is an ics for an event entered in OWA for a meeting at 21:00 > (exported from Evolution) : > BEGIN:VTIMEZONE > TZID:Romance Standard Time ... > END:VTIMEZONE > BEGIN:VEVENT > SUMMARY;LANGUAGE=nb-NO:Test entered for 21 in OWA > DTSTART;TZID=Romance Standard Time:20130601T210000 > DTEND;TZID=Romance Standard Time:20130601T220000 This one defines a time zone, then gives the meeting start/end in terms of that timezone. It looks fine. > This is an ics of an event entered in Outlook as exported by Evolution: > BEGIN:VCALENDAR > PRODID:-//Ximian//NONSGML Evolution Calendar//EN > VERSION:2.0 > METHOD:PUBLISH > BEGIN:VTIMEZONE > TZID:(GMT+01:00) Amsterdam\, Berlin\, Bern\, Rome\, Stockholm\, Vienna > ... > END:VTIMEZONE > BEGIN:VEVENT > SUMMARY;LANGUAGE=nb-NO:Test 2100 entered in Outlook > DTSTART;TZID="(GMT+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, > Vienna":20130531T210000 > DTEND;TZID="(GMT+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna": > 20130531T213000 Same thing, looks fine. Except for that stupid cosmetic Microsoft bug where the textual name of the time zone which is currently GMT+2, has the text "GMT+01:00" in it. Stupidly. -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
