So I don’t have to subject myself to my company’s Draconian MS Intune policies, I have a small Perl script that grabs an ical export from my O365 account and throws it onto a web server of my own. ICSDroid then picks it up on a regular basis and syncs it to a local calendar on my Android.
In the past fortnight, we’ve just gone to daylight saving here in Australia, and now I have a bunch of recurring appointments that are an hour out. As best I can tell from reading up on the ICAL v2.0 format, the ics export from O365 seems correct, but I thought I’d ask here, to confirm.
Below is the VTIMEZONE for my region, defined at the top of the ics file:
METHOD:PUBLISH
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
X-WR-CALNAME:Calendar
BEGIN:VTIMEZONE
TZID:(UTC+10:00) Canberra\, Melbourne\, Sydney
BEGIN:STANDARD
DTSTART:16010101T030000
TZOFFSETFROM:+1100
TZOFFSETTO:+1000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=4
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T020000
TZOFFSETFROM:+1000
TZOFFSETTO:+1100
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=10
END:DAYLIGHT
END:VTIMEZONE
Here is a working, single instance appointment:
BEGIN:VEVENT
DESCRIPTION:\n\n
UID:040000008200E00074C5B7101A82E008000000009086EF437120D201000000000000000
010000000345B548E548DD54183F40100FB585F3F
BEGIN:VALARM
TRIGGER:-PT15M
ACTION:DISPLAY
END:VALARM
SUMMARY:Coffee with John
DTSTART;TZID="(UTC+10:00) Canberra, Melbourne, Sydney":20161013T093000
DTEND;TZID="(UTC+10:00) Canberra, Melbourne, Sydney":20161013T100000
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20161012T215624Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:0
LOCATION:Mulgrave
X-MICROSOFT-CDO-APPT-SEQUENCE:0
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
And here’s a recurring appointment that, just started showing an hour wrong since we went to DST:
BEGIN:VEVENT
DESCRIPTION:\n\n
RRULE:FREQ=WEEKLY;UNTIL=20170413T020000Z;INTERVAL=1;BYDAY=MO,TU,WE,TH,FR;WK
ST=MO
EXDATE;TZID="(UTC+10:00) Canberra, Melbourne, Sydney":20160908T120000,2016091
3T120000,20160916T120000,20160921T120000,20160922T120000,20160929T120000,2
0160930T120000,20161003T120000,20161004T120000,20161005T120000,20161006T12
0000,20161014T120000
UID:040000008200E00074C5B7101A82E0080000000030535CB86D9BCB01000000000000000
010000000485D55228B56E540A801BD90D9DE47E6
SUMMARY:Lunch/walk
DTSTART;TZID="(UTC+10:00) Canberra, Melbourne, Sydney":20160713T120000
DTEND;TZID="(UTC+10:00) Canberra, Melbourne, Sydney":20160713T130000
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20161012T215624Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:0
LOCATION:
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-BUSYSTATUS:BUSY
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:1
X-MICROSOFT-DISALLOW-COUNTER:FALSE
END:VEVENT
I’m still trying to decipher the additional data in the above recurring event, but I’m hoping someone more au fait with the format can easily identify what’s going wrong, or at least point me to the dodgy data, so I can write some Perl to remedy it.
Cheers.
Hello,
Did you try the timezone definition (+ ID) from Olson DB/ical4j? For Sydney, this would be Australia/Sydney.
Interesting - I think Office 365 had some sort of tempoprary export bug, as the appointments have all corrected themselves, and the TZID has changed for all appointments:
DTSTART;TZID=AUS Eastern Standard Time:20160714T120000
DTEND;TZID=AUS Eastern Standard Time:20160714T130000