Still Getting DST Issues Here...

  • Article

Believe it or not, we're still getting calls on the recent Daylight Saving Time changes. Most of the time it just turns out to be an unpatched server somewhere, but this last one I got had most everybody stumped. The customer was reporting that meeting requests sent from their Sharepoint server showed up an hour off when they were received in Outlook, but only if the meeting was scheduled for the first week of November. They also noted that meeting requests "received from the Internet" were also an hour off.

Now - that's the classic description of an unpatched machine, but an inventory of their Exchange and Sharepoint servers showed that all were patched correctly. Same for all the client machines.

I picked up the issue as it got escalated up the chain. First thing I did was to ask them what they meant by requests "received from the Internet". They explained that if you set up a Gmail account with a calendar, then exported it as ICS and imported it to Outlook, the meetings in the first week of November would be off by an hour. I figured there's really only two scenarios to consider here:

  1. The ICS exported from Gmail is correct, and Outlook is parsing it wrong
  2. The ICS exported from Gmail is incorrect

Ok - so this was simple enough to test out. I signed up for a Gmail account, created some appointments, and shared my calendar out so I could grab the ICS. And sure enough, when I imported it into Outlook, the appointments were wrong.

Here's the URL to my Gmail calendar: https://www.google.com/calendar/ical/mfcmapi%40gmail.com/public/basic.ics

When I first downloaded this ics file, it contained the following (truncated of course):

BEGIN:VTIMEZONE
...
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
...
RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1SU
...
END:VTIMEZONE

The first RRULE there roughly translates to "Yearly on the last Sunday in October" and the second to "Yearly on the first Sunday in April". That's the old Eastern timezone definition. So of course the meeting looks funny when read in to Outlook.

If you look at my Gmail calendar now though, you'll find the correct RRULEs. This happened when I switched my Gmail timezone to another timezone and then back to Eastern. I don't know if anyone else is having problems with .ics exported from Gmail, but if you are it's worth trying this.

Back to the customer's issue - maybe they were having the same problem? After all, Sharepoint isn't really MAPI aware, so any meeting request it sends is likely to be iCalendar. I asked them to include me on one of their meeting requests. Here's what I found in the .ics they sent out:

PRODID:-//Advanced Intellect//aspNetEmail Calender Writer(v3.5.2.0)//EN
...
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=10;BYDAY=-1SU
...
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=4;BYDAY=1SU

Whaddya know? There's those old timezone rules again. Most interestingly, that PRODID indicates it's not even Sharepoint that created this .ICS, but instead a component called aspNetEmail, created by a company called Advanced Intellect. A little digging on their site finds their post concerning DST. Double checking their change log confirmed that they took a fix for DST in build 3.6.0.3. As soon as the customer applies the update to aspNetEmail, they should be back in business!

BTW - In all fairness to the guy that called the problem in - he didn't know that his Sharepoint guys were using this component. He accepted at face value that when they said they "sent the meeting request with Sharepoint" it meant Sharepoint was really sending the meeting request.