troubleshooting Question

Exchange ActiveSync UTC for Calendar Items

Avatar of lrwdigital
lrwdigital asked on
ExchangeMicrosoft ApplicationsMicrosoft Development
9 Comments1 Solution462 ViewsLast Modified:
Color me a bit confused. I am attempting to write an IOS client application to communicate with Exchange ActiveSync and display calendar information. But I am seeing some conflicting information in the protocol docs when compared to what I am getting from Exchange. Either that or I am somehow misinterpreting one or the other.

My intent is to save an appointment in my local database in Coordinated Universal Time and then have the UI read in the information and display it as appropriate to the local timezone. In this way an recurring appointment created before daylight saving time for Noon will still be at the same time of day in local time as an appointment created during daylight saving time for noon. But they are not.

My understanding of the documentation is as such:

In MS-ASCAL pdf section (roughly page 34) it says for Start Time that : ...the value of this element is a dateTime data type as specified in MS-ASDTYPE section 2.3.

Moving to MS-ASDTYPE section 2.3 (roughly page 7) the dateTime value is specified in the format of ISO-8601 and all dates are given in Coordinated Universal Time (UTC)

Looking up coordinated universal time I see that UTC does not changed with the seasons as local or civil time does and therefore DOES NOT support daylight saving time. This makes sense, as DST is decidedly local and is ignored by many areas. You cannot know from the perspective of UTC whether or not to apply a DST offset without knowing what timezone and area the time represents, therefore no daylight saving time can be supported. Based on this information I should be able to just slap the dates into my database as they are and merely have the UI adjust itself to display them properly.

However, as a tested I began seeing a divergence of an hour between the two appointments in the database before the UI has even read them. To confirm this I created two recurring appointments representing Lunch at 12 noon local time. One that starts on March 1st 2014 (Standard Time) and one that starts on March 10th 2014 (daylight saving time) in the eastern timezone. This should be March X 2014 at 1700 hours in both cases should it not?

In the WBXML/XML that I am receiving I am getting two different times. The appointment that starts during standard time gives me a start time of 20140301T170000Z. The appointment that starts after daylight saving time is in effect locally gives me 20140301T160000Z.

The difference between the two times is 1 hour, which is the daylight saving time offset. It is my perception based on everything that I have read both in the microsoft protocol documentation and outside it that these two times should be the same and that whatever client that gets to display them should be the one putting the offset in place as needed. Noon local time is noon local time but local time is the province of the local municipality/timezone, not that of UTC.

So my question is what exactly is going on here? Are the start/stop/date stamp date times in UTC or not. If they are in UTC, then why are they offset by an hour instead of being at the same time? Obviously outlook displays these correctly for local time, because both appear at noon. But in my case my database contains locally adjusted times instead of the UTC times I thought I was getting which is throwing off when those appointments appear in the UI.

Can someone please clarify what's going on here and what I should be seeing?

"Batchelor", Developer and EE Topic Advisor
Join our community to see this answer!
Unlock 1 Answer and 9 Comments.
Start Free Trial
Learn from the best

Network and collaborate with thousands of CTOs, CISOs, and IT Pros rooting for you and your success.

Andrew Hancock - VMware vExpert
See if this solution works for you by signing up for a 7 day free trial.
Unlock 1 Answer and 9 Comments.
Try for 7 days

”The time we save is the biggest benefit of E-E to our team. What could take multiple guys 2 hours or more each to find is accessed in around 15 minutes on Experts Exchange.

-Mike Kapnisakis, Warner Bros