Writing code for calendaring features is hard. Some of you might say writing any kind of code is hard, and you might have a point, but calendaring is particularly tricky. Why’s that? Well, consider time zones for a start – a meeting you set up isn’t necessarily in the same time as it is for me, and then you also invited people, from a whole bunch of other time zones (did you know some time zones are 30 mins off, not a full hour?), and then you made the meeting recurring, not every week, but every third Monday, except for next month, when it’s on Tuesday… and so on and so forth. But you got a meeting set up, all good.
And then one of the attendees happens to live in a country that decided to implement Daylight Saving Time (DST) and change the local time by an hour. Just in that country.
And we have an good example, as Brazil changed their DST rules in 2019 to eliminate DST and those changes are coming up very soon and they might impact users even with the latest OS updates applied. Users may see various issues with "off by an hour" calendar items when using the Brasilia time zone.
Sometimes we get caught out by a DST change made by a country, or a particular change needs us to code something new to account for it, and for the most part we make it so you don’t notice. But despite our best efforts sometimes users notice meetings are off by an hour. Then the users call you, their IT Pro to complain.
What do you do? There are a number of things we recommend, and so we wanted to share some simple advice on what to do, if it happens.
The “off by one hour” issue can vary widely in terms of scope and symptom, although it is typically limited to recurring appointments and meetings. For example, a user might report:
- Every single recurring meeting is off by an hour, but only in Outlook on the Web (OWA). The meetings render correctly in Outlook for Windows.
- Only a few meetings are off by an hour, but they show incorrectly in both OWA and in Outlook for Windows.
- Only exceptions to a recurring meeting are off by an hour, and only for attendees, not for the organizer.
- Only existing meetings that were created BEFORE the Windows Operating System DST patches were applied are off by an hour.
- Some other possible variation of meeting creation, attendee vs organizer, all vs some, OWA or Outlook desktop, etc.
The #1 best thing you can do to avoid seeing these issues in the first place is to keep your client software and operating system up to date. Sorry if that’s obvious to you, but the OS is the master time source for the client (in OWA’s case that means Exchange Online), and sometimes these DST patches require an update to Windows/Mac/Linux – so keep them patched. Sometimes we need to patch Outlook for Windows, Mac, iOS or Android, and so keeping the client up to date can prevent these issues from showing up. There’s a strong case to be made here for switching to Office 365 ProPlus and having updates regularly applied.
These DST issues can also require server-side changes. Exchange Online does all that for you, of course. In an on-premises world you need to update your servers, so make sure you keep up to date on CUs and OS updates.
Assuming you’ve done all that, your clients and servers/services are up to date – what then?
You need to figure out how large the scope of this issue is for your users. Is it every user? Is it Outlook for Windows only? What about OWA, does that work? Because the easiest thing might be to have the user switch to another client app until you figure it out.
If it’s only a subset of users (as you only have a small number of users in that geography where DST changed the time) perhaps you decide to manually ‘fix’ the meetings. If so, here’s what we suggest;
- Make sure the DST patches/updates are in place.
- Make sure you note any existing meeting exceptions that might exist if the problem meeting is recurring.
- Have the organizer cancel the meeting that is problematic.
- Have the organizer create and send a new meeting so that the start time correctly takes into account the new DST rules.
- Recreate the needed exceptional instances.
We also see cases where users ‘fixed’ their meetings ahead of a patch/update by just dragging them to the ‘correct’ start time, which then results in them breaking again when updates are installed (and their automatic changes come into effect) – that’s confusing but it’s all the same issue.
We realize re-creating the meeting series is a bit inconvenient, but that’s because time zone rule information is stored on the meeting itself and re-creating it on a patched machine will ensure the correct rules are being used for that series. And it’s often the quickest solution. But what if the impact is too large to handle that way, and you’ve made sure your clients are patched – then you should call into support and get some advice.
On multiple occasions we have made service side changes in Exchange Online to ‘fix’ it there. Those changes do make it to on-prem, but not until the next CU typically.
We give you a lot of flexibility in how you can create meetings (and we are not done improving meetings by a long shot) but it sometimes feels like it’s something of a minor miracle any of us ever get to meet and talk to each other at all, it really is. We celebrate people meeting every day, and we work really hard on this stuff, all the time, to make sure changes such as DST are accounted for.
We’re working on the Brazilian DST issue very hard right now, but we want to call it out so admins with users in that timezone are aware, and have a chance to make sure patches are applied, users are aware and so on. We’ll get things patched and fixed in time, no doubt, but we thought this a good time to broadly discuss DST, what it means, what you can do, and why writing code for calendaring can sometimes be a bit hard.
The Calendaring Team
Microsoft
