By: Aaron Cohoon
We’re getting reports from users on both AppRiver’s Hosted Exchange and Microsoft Office 365 platforms that calendar events are displaying two time zones on iPhones and iPads running iOS 8. Calendar events that were created on an iPhone or iPad running iOS 8 or higher, or created in Microsoft Outlook in some cases, display the server time below the device’s local time when opened on an iPad or iPhone running iOS 8.0.0 through 8.1.1.
In this example the user’s mailbox server is hosted with Office 365 in GMT:
While this issue seems to be cosmetic since the device’s correct local time is still displayed in the calendar, it can potentially cause major confusion for users when they edit an event from an iPhone or iPad, as the Start time will default to the server time. One user has created a video detailing the issue and challenge it causes with editing events and posted it on YouTube here.
To edit an event displaying two time zones tap the Start time field, and make sure the time zone is correct before saving the changes to the calendar event on the device. This won’t prevent the server time zone from being displayed, but it will keep your calendar appointments set to the correct time when editing events on the go
Why is this happening?
Several users have reported this issue to Apple, and in one case the following response has been forwarded from Apple Support:
“The customer is contacting us because both the local time, and either the time of the originator or the server is showing in the Calendar app. This is expected behavior with iOS 8.The customer can submit feedback on this feature at http://www.apple.com/feedback.”
This is not behavior observed with other email and calendar clients supporting Exchange such as Outlook, Android, Windows Phone, or BlackBerry mobile devices. Calendar events should display the time zone the event was created in as determined by the client software (Outlook or the settings on your mobile device) not the time zone in which the server is housed. Time zones are controlled at the individual mailbox client level because each Exchange server can, and does house mailboxes of users who live, work, and travel throughout different time zones.
Time Zone override is the only feature in iOS 8 that is known to display two time zones in a calendar event. Since Time Zone Override replaced the Time Zone Support feature in iOS, we can assume its expected behavior is to display events in an iOS device’s local time as well as the time zone in which the event was created.
For example, you live in New York, your time zone is EST, and you are traveling to London, in GMT, when you get to London you’re time zone is 5 hours ahead of New York time, but you have to call a client back home at 4 PM EST. The Time Zone override feature should display your calendar events that were created in New in both EST and GMT
Unfortunately, users are seeing their server times displayed while they’re home and all of their client settings are set correctly to New York (for this example). I have reported this as a feature bug to Apple as this happens even when Time Zone Override is turned off. To further confuse the perception of “expected behavior”, Apple has not included Time Zone Override in the official IOS 8 (now 8.1) manual as of today.
After extensive troubleshooting and providing several examples to Apple Support, my ticket on the issue was escalated to Apple’s Engineering team. Unfortunately there is still no fix, but I have been assured there is something in the works. Apple’s Enterprise team sent me an acknowledgement after their Engineering team reviewed my case and that of several other users.
“Thank you for calling in so we may add to impact on issue with Exchange accounts and calendars on ios 8. Apple is aware of this and currently being worked on.”
From what they’ve told me they have enough examples now to know the issue with dual time zones displayed in events is specific to an iOS 8 feature. However, I was also informed the reported impact has been minimal. In order to increase awareness so that there can be a fix applied in an update soon I encourage any user encountering this issue to submit feedback at the following web address: http://www.apple.com/feedback/iphone.html