In this article we will:
- Briefly introduce Daylight Saving Time, aka Summer Time
- Discuss its impact on remote or geographically-distributed meetings
- Explain how time zones work when scheduling meetings in LFX Project Control Center (PCC)
Daylight Saving Time
Daylight Saving Time (DST), also known as Summer Time, is controversial but has been implemented in many countries to adjust “wall clock” time, twice a year, to maximize daylight during waking hours. Proponents suggest it reduces energy use, among other things. At the same time, opponents argue that the rules are not only complex but also have adverse effects on health, like disrupted sleep cycles and a reduced hour of sleep once a year.
At present, most localities in North America and Europe observe DST, while nearly all localities on other continents do not. To make matters more confusing, the localities that observe DST do not all start (or stop) at the same time, nor is DST observance consistent even within a country—for instance both the United States and Australia not only have states in different time zones, but they also have states which observe DST and states which don’t.
DST Countries Map
blue: uses DST (N hemisphere); orange: uses DST (S hemisphere); light gray: formally used DST; dark grey: never used DSTAuthor: TimeZonesBoy, CC BY-SA 3.0 https://creativecommons.org/licenses/by-sa/3.0, via Wikimedia Commons
What does DST have to do with meetings?
For any sufficiently distributed organization, like the Linux Foundation, or the open source projects and communities we support, it will usually not be possible to hold a meeting at a consistent time-of-day, throughout the entire year, for all participants.
- We will demonstrate this by having two meetings with participants from Los Angeles (California, USA) and Phoenix (Arizona, USA), as well as London (UK), Tokyo, Japan, and Sydney (New South Wales, Australia).
- Yes, it’s unlikely you’d actually have a single recurring call to regularly accomodate everyone in these exact time zones! The effects shown still happen if you have just Los Angeles and Sydney, or just London and Tokyo, etc.
- In most personal calendaring tools, a scheduled recurring event is consistent with the timezone of the scheduler.
- Our first meeting example shows what would happen if it remains consistent to the local time of the Los Angeles participant.
- Our second meeting example shows what would happen if it remains consistent to the local time of the Phoenix, Arizona participant.
What happens if the meeting time is “pinned” to Los Angeles?
First, let’s look at Phoenix and Tokyo.
They don’t observe DST, so when Los Angeles stops observing DST and keeps the meeting on at the same time, it will shift to a new time for Phoenix and Tokyo until next spring, when it will change back.
What about London?
London stops observing DST a week before Los Angeles, so the meeting changes for them when London starts observing and Los Angeles isn’t, and then when Los Angeles cuts over, London reverts to the same “wall clock” time they had before (for the rest of the winter). This happens in reverse in spring, for 4 total meeting shifts in a year.
What is happening in Sydney?
First, Sydney cuts over a month earlier than Los Angeles. However, they aren’t stopping DST: they are starting DST. They are shifting their clocks the other way. And then, when Los Angeles starts observing DST and moves the meeting, it’s now two hours different for Sydney than it was a month prior! And, like London, it’s total of 4 shifts in a year.
What happens if the meeting time is “pinned” to Phoenix?
Like Phoenix, Tokyo also doesn’t observe DST, so its meeting never shifts. For the other time zones, they each see the meeting shift whenever their locality starts (or stops) observing DST—which would be two times a year, maximum, and never by more than 1 hour.
Therefore, assuming a geographically-diverse community, “pinning” the meeting to a non-DST-observing timezone results in less disruptive shifting overall: a maximum of 2 shifts per year instead of 4, and a maximum of 1 hour change instead of 2.
How does LFX Project Control Center handle this?
Today, LFX Project Control Center always uses Coordinated Universal Time (UTC) to apply meeting recurrence patterns, though it allows the user to set the meeting time and date (for the next occurrence) based on their local time, and participants always see local times for meeting occurrences in Individual Dashboard and in their personal calendaring software.
UTC does not use DST, so meetings scheduled in Project Control Center act like our second example (Phoenix).
There are projects at the Linux Foundation which have explicitly adopted UTC scheduling as their standard, because of the negative effects of pinning a meeting to a DST-observing locality, and your project may want to consider this.
Support in Project Control Center to “pin” meetings to a specific timezone/locale (DST-observing or otherwise) is a feature request we are tracking, but it is not currently on the roadmap.
What can you do if we haven’t convinced you to adopt UTC scheduling?
In LFX Project Control Center, you can break your existing meeting into two recurring meetings at any point in time prior to your local DST transition. In the recurring rules for your existing meeting, select the “Custom” rule, and set the correct number of remaining meeting occurrences that will line up with when your locality starts or stops observing DST. Then, schedule a new recurring meeting for the subsequent meeting date, at your same local time.
Let’s use the example recurring Thursday meeting above: say you’re in Pacific Daylight Time (Los Angeles) currently, and your meeting is looking like the second example, but you want it to look like the first example. Assuming today is October 21st, then you know there are 2 more occurrences before the US DST observance ends (and the meeting currently appears to shift in your own personal calendar). You can edit the meeting in PCC, set a Custom recurring schedule, and tell it to end after two more occurrences. You can then schedule a new meeting for November 10th at 9 pm, recurring weekly. PCC knows that even though you are currently in DST (Pacific Daylight Time), you are scheduling this for 9 pm on the 10th, after the US stops observing DST (Pacific Standard Time). The meeting you schedule with a start time of the 10th won’t change when your clocks fall back. (Note, however, that the participants will now have a different personal join link starting on November 10th.)
We welcome your questions and feedback. Please reply below!
) time, and will shift for any participant (including the admin who scheduled it, assuming they are also a participant—which isn’t a requirement) when DST stops or starts in their locality—unless they are in a locality that doesn’t use DST, and then it won’t ever shift.
