This is where things get a bit interesting. What you can do is to go to you personal settings, change it to Auckland (GMT + 12), which you can see in the picture below.
Now, click ok, and you can book you meeting at 1 PM, invite all people that are supposed to attent and save it. Then return to your own time zone, in my case GMT+1 for Stockholm and the meeting time jumps to 3 AM as seen in below picture.
Ok, so far, so good. But if you’re in an international organization and you book a bucketload of meetings every day, doens’t this mean there will be a LOT of clicking?
The short answer is, yes, there will be a lot of clicking. How much you might wonder.
I have actually done the math. Now, considering that you change the time zone of your personal settings for each meating you book you need 5 clicks to get to the desired time zone, then wait for the form to reload and you can enter the start time of the meeting, and then save. If you want to return to your own time zone after saving, it’s another five clicks, since you might want to check when the heck the meeting will take place in some civilized time zone, even thought the start time will most likely be far from civilized.
Now wait, if you’re booking a lot of meetings, you might have several meetings in the same time zone you might think, and you don’t have to check your own time zone each time you book a meeting.
Fair enough, let’s say you book 16 meetings a day in at least 4 different time zones, that will give you at least 25 bonus clicks which might not seem much but you also have 5 reloads of the form that make the application perhaps not seem like the most smooth tool in the box. The customer will most likely point out that you can have different time zones for start and end time if you make the booking in outlook, so why on earth isn’t it possible to book a meeting in a different time zone in CRM?
One can only speculate on the reasons, it is for sure that the reason isn’t that the application is from USA since USA alone has a couple of time zones. I seriously have no good answer to this.
The reason why I’m writing about this is of course since I have run into this with one of our customers. So how can you solve this?
There must be a couple of solutions to this and I will show you our solution but first a bit of background.
– One, there is a timezone format of the whole number field. It’s broken, don’t use it. I tried to use it and as soon as I inserted data in the field I got an error. I started a thread on connect for this issue, so please vote on Connect if you have an account so that might get fixed.
– Two, event with that field functioning, it’s no walk in the park to make the time zones work…
– Three, all datetimes are stored in the database in Zulu time, which is UTC, ie, no daylight saving whatsoever, which I will come back to later. This means that you will have to do something with that time if you’re working with the start/stop time programatically.
-Four, did I mention daylight savings? Yes, that will make it trickier.
-Five, and this is someting I didn’t think about but I discover it rather harshly, you computer and your CRM might very well be running on different time zones.
-Six, did anyone say daylight saving?
Keep the start and end time fields, you will need those, and add extra fields for start and end time which will show the start and end time of the meeting where the meeting takes place.
Right, this can be done, but how do we know in which time zone the meeting takes place?
Add a time zone field.
Ok, so how do we keep these fields updated? Let’s write som js to keep them updated, take the time from CRM, add or subtract the relevant time difference and everything’s fine. Well not quite.
I will continue on the solution next time, which I promise won’t be another six months.
Developer at CRM-Konsulterna