Is There a Workaround for lack of Olsen TZ TZID Fo

Question

I recently had a problem with an ICS file that I received in email. My copy of Outlook 2010 would not recognize the timezone correctly. Here is the way that the start time of a meeting was represented in the ICS file:

DTSTART;TZID=America/Los_Angeles:20110928T183000

When Outlook imported this file, it changed the time from 6:30 pm Pacific time to 7:30 pm Pacific time. After some experimentation I was able to get an ICS file that imported correctly in Outlook by changing the time zone format:

DTSTART;TZID="Pacific Time":20110928T183000

After some further research I found that the ICS file specification leaves the question of time zone identification open, but suggests using the Olsen TZ database. It appears that the Microsoft Outlook team has chosen to ignore this suggestion.

Given that Outlook is a fairly popular calendar client, is there a reliable way to format ICS time zones for Outlook that is still compatible with other clients? My biggest concern about this issue is the silent error during the Outlook import. Users could easily show up for a meeting at the wrong time, since Outlook gives no warning that it's confused about the time zone. Should we simply direct Outlook users to a different file format?

Note: I know that this question is similar to an earlier post, but the references on that post appear to have expired, and I'm wondering if there are any better solutions out there.

Answer 1

Hard to judge without the full iCalendar file but did you define/do you have a VTIMEZONE component in your calendar file which defines what America/Los_Angeles should be?

Something like:

BEGIN:VTIMEZONE
TZID:America/Los_Angeles
BEGIN:DAYLIGHT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
DTSTART:19700308T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:19701101T020000
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE

Answer 2

Instead of adding the timezone definition to the ics file, it would be better to mention the event start/end times in UTC itself. And then, the consumer of the ICS file - outlook in your case - should be able to do the timezone conversion from UTC(from ics file) to the preferred timezone setting of the end user, just before rendering the meeting event on their calendars.

Pros: This way you dont have to take care of adding the correct timezone offsets (VTIMEZONE component) yourself. Plus, the ics file is much smaller, cleaner, easy to read.

References: Even google seems to be handling timezones in ics this way itself - Google timezone handling

Hope this helps.