How calendar events are seen in different time zones

One of the most important features of the new calendar portlet is the ability of consistently showing events to users in different time zones. It is invaluable for global organizations. If your team is scattered around the world, you would really want to make sure things happen at the same time!

However, the consistent behavior can be quite difficult to grasp. It is understandable that 9 AM in São Paulo is 1 PM in London... when there is no Daylight Savings Time. Now, if it is 9 AM in São Paulo, what time is it in London if the United Kingdom is under summer time? What time would it be in London if São Paulo is under summer time? And when both cities are in DST? Recurring events make these questions yet more baffling. Your Paulistano colleague would see that meeting, which used to happen at 9 AM, just changed to 8 AM... Working it out can drive one crazy! (Not me, of course; I work with it all the time but I'm completely sane.)

Luckily, those calculations are no job for humans, the calendar handles it all. Nonetheless, one may need to know how calendar works with diverse time zones; otherwise, one could choose bad times for events and get lost with some strange behaviors. Here we will see what is needed to know.

How users in different time zones see events

Consider an hypothetical company which uses Liferay and the calendar portlet. The company's portal time zone is set to the Coordinated Universal Time (UTC). Also, this company has two employees: Brian, who lives in Los Angeles, and Juán, who lives in Madrid. Brian went into his account configuration and, in the section "Display Settings", changed his time zone to be America/Los Angeles; likewise, Juán changed his time zone to Europe/Madrid.

Now, Brian schedules a meeting with Juán at February 3, 2014. In the calendar, he clicks in the row labeled "8 AM" to create the event:

Once Brian creates the event and invites his colleague, Juán will see the following event in his calendar:

To Juán, the event appears at 5 PM (or 17:00) since this is the corresponding time in Spain:

Note, however, that neither Los Angeles nor Madrid are under daylight savings time. Would Brian schedule the event to March 24 (when Los Angeles is under DST), the meeting would appear in Juán's calendar at 4 PM:

As you can see, the events are displayed in an specific hour depending on the authenticated user time zone. If the user is not authenticated, however, the events are going to be displayed in the portal time zone. So, for example, an unauthenticated user would see the event from February 3 at 4 PM, since this is the corresponding hour in Universal Time; the meeting at March 24 would be displayed at 3 PM to the guest user.

Time zones and recurring events

Users who deal with partners in different time zones probably are used to these details. Subtler than these differences is the behavior of recurring events.

Recurring events are trickier because they should happen in the same hour of the day, all days. Suppose, for example, that Brian scheduled meetings with another colleague from LA every Monday at 10 AM. They would expect the events to always be scheduled to 10 AM regardless of whether DST is in effect or not. Both the meeting at March 3 and the meeting at March 31 would happen at 10 AM in Los Angeles time, although the former would happen at 6 PM (18:00) UTC and the latter at 5 PM (17:00) UTC.

For achieving this behavior, Brian just needs to create the recurring event in his own calendar. Since his user time zone is America/Los Angeles, the calendar portlet will make the event fixed in the same hour at this time zone.

When users are on different time zones, the schedule time should be fixed on only one of the time zones. Otherwise, the same event would be scheduled for two different moments in time! Suppose, for example, that our colleague Brian wants to have weekly meetings with Juán. Brian then creates a recurring event in his own calendar, recurring every Monday, at 8 AM (Los Angeles time), starting at March 3; also, he invites Juán to the event. What will Juán see?

Well, that depends on the Monday Juan is looking at:

  • At March 3, the meeting will be scheduled for 5 PM:

  • California will be under daylight savings time from March 9 on; LA clocks should have one hour added to them. So, at March 10 Juán will see the event happening one hour sooner, at 4 PM:

  • For its turn, DST will start in Spain at March 30, so an hour will be added to each clock in Madrid. This will synchronize them with the Los Angeles clocks, so, at March 31, Juán will see the event scheduled for 5 PM:

As you can see, for consistency, the event can only be fixed in one time zone. For users in other time zones, the event will keep changing its start and end times. It can be a bit dizzying but the user does not need to track it at all. Juán would only need to be aware that the meetings could happen in different times - the calendar will always display the correct hour and minute. With proper notifications, he would be informed of the correct time in a timely manner.

If Brian and Juán prefer the event to be fixed in the Madrilenian time zone, then Juán would create the event in his calendar, since his time zone is the Spanish one. If, on the other hand, the event would be created in a site calendar, the recurring event would be fixed in the portal time zone - which, in our example, is UTC.

Which time zones affects the event times?

As you can see, each time an event is rendered in the screen there are two time zones to define its start and end times. The first one is the time zone of the user who sees the event. This display time zone is important to define the hour to be displayed but has no influence on the exact moment the event will take place. It can make the event appear at 8 AM to an LA-located user and 17 PM to another user at Madrid, but it is showing the same hour, since 8 AM in Los Angeles time is the same as 17 PM in Madrid time.

Most of the time, the display time zone will be the time zone the authenticated user has chosen in her Display Settings. If the user is not authenticated, it will be the portal time zone.

There is a way of forcing the calendar to always use the same arbitrary display time zone in a site: just go into the Calendar portlet preferences and disable the "Use Global Time Zone" option at the bottom of the screen. Then, select the time zone you would want to be used by the Calendar as the displayed one. This configuration is site-scoped: the events will be displayed in the selected time zone in all pages of the configured site, regardless of the user time zone.

Apart from the display time zone, each event is associated to another time zone. This one is only relevant for recurring events, since this is used to "fix" the event on a specific hour of the day; since the event is going to be "fixed" it is important to know in which time zone the hour and minute will be the same regardless of the day. This event time zone is derived from the calendar in which the event was created. If the event was created in a user calendar, the the event time zone is the user time zone of its creator. If, otherwise, it was created in a site calendar, the event time zone will be the portal time zone.

  What does it affect? How it is defined? When is it relevant?
Display time zone It defines at which time zone the events will be displayed. In our examples, it defines whether de event is displayed in Los Angeles time our Madrid time.
  • If the portlet configuration was changed, it will be the time zone selected in the portlet configuration
  • If the portlet configuration was not changed:
    • If the user is authenticated, it will be the user time zone.
    • If the user is not authenticated, it will be the portal time zone.
Always: no event can be rendered without taking into consideration the display time zone. After all, the hour should be displayed in some specific time zone.
Event time zone In recurring events, it defines the time zone at which the hour and minute should be the same. In our examples, it defines that an event should happen always at, let us say, 8 AM in Los Angeles time regardless of whether LA is under daylight savings time.
  • If the event was created in a user calendar, it will be the user time zone of the event creator.
  • If the event was created in a site calendar, it will be the portal time zone.
Only when rendering recurring events.

An experienced reader will feel the need of choosing the event time zone. If the organization of our example does have a site for its office in Madrid, the events created on this site calendar would be preferably bound to the Madrid time zone, not to the portal time zone, which is UTC. Also, I may create an event on my own site but decide that it should be bound to another, completely different time zone. Alas, this is not possible now, but a ticket is already filled for that and this feature will be available in the next major release.

Many may find all this stuff bewildering. Don't worry: most users will never need to think about it. The decisions a user has to make are much simpler. Do you want to see the events in Los Angeles time or in Madrid time? Do you want your weekly event to happen at the same hour in which city? You just need to answer these straightforward questions. The calendar portlet will take care of the details for you - in a consistent way.

Blogs
Oh yeah. Add locale to this and you'll get totally crazy: Suddenly 1pm is 13:00 and March 10 is either 3/10 or 10.3. And if you tl;dr the article, try https://www.youtube.com/watch?v=-5wpm-gesOY to truly appreciate the work that goes into timezone matters. Aren't we all adult enough to finally agree on a single timezone? ;)
Ha, great video indeed, thanks! I can relate to that. And you may feel happy to know that there is a incipient movement advocating for a single time zone: https://www.youtube.com/watch?v=c3EQDfqqHsI (I doubt it will happen soon but it should start at some point, after all.)