How to manage Daylight Saving Time when Scheduling Meetings in Project Control Center

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 DST

Author: TimeZonesBoy, CC 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!


We didn’t mention it in the original article, since it has nothing to do with DST, but there is another significant implication of timezones on meetings, and this is its impact on monthly recurring schedules. It’s simple enough to know that, if I schedule a weekly meeting on Tuesday, it might actually be on a Wednesday for other folks, or vice versa: for instance, I have a late afternoon meeting which is early in the morning for my colleagues in Australia. But if I held that meeting on the afternoon of the “second Tuesday of the month”? For those colleagues, some months it will be the second Wednesday of the month, and other months it will be their third Wednesday (for any month where the 1st falls on a Wednesday. So you can’t have the same stated monthly rule apply in a “consistently-observable” way for everyone.

PCC is a shared portal for multiple administrators, probably in different timezones, to schedule and manage meetings with participants in many timezones. And because (today) it only supports applying meeting recurring patterns using UTC, whenever you schedule a meeting whose weekday (in UTC) differs from the weekday in your local timezone, PCC shows you the effective UTC weekday, with a note saying it’s the UTC weekday instead of your local timezone’s weekday for that date/time, to help avoid any surprises when you are scheduling a recurring monthly meeting and it lands on a different week in your calendar than you thought it should!


Thank you for sharing this here @emsearcy ! I know many of our project administrators had questions on how LFX meetings would handle day light savings globally.

So what you’re saying is, PCC handles meetings over DST, as they were scheduled for the administrators local time? And if DST comes the meeting won’t shift to another hour based on location, but will stay consistent to the original set up meeting time based on the administrator’s local time.

So depending on location of other participants in the meeting their meeting times may shift, but through DST the meeting will stay consistent to the original appointed meeting time for the local administrator, correct?

Hi @emsearcy - I appreciate this write-up.

I think the reality is that many of our projects standardize on US time zones because they are US centric, so the idea of having to move to UTC time zone is just going to be an annoyance to them, and I could see them changing meeting invites when DST begins/ends.

Is there a technical reason why we couldn’t support the option of standardizing to a timezone vs UTC?


I can’t 100% follow what you’re saying, but if you are saying, it won’t shift time for the person that scheduled it but it may shift for others (which, is actually what my FIRST example grid of meeting times shows)—*no*, that is not the case. PCC uses the example of the SECOND example grid of meeting times: the meetings stay at the same “absolute” (solar :wink: ) 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.

1 Like

@John_Mertic yes, I understand that too. I was hoping to illuminate the side effects of a “US centric” way of doing things … this may not matter as much for a board if you know where everyone is, but for open community calls, I believe we can foster diversity and inclusion by not causing 2 hour shifts (for the other hemisphere) and 4 meeting-time-changes-a-year for others in the community. (Not to mention, with the Sunshine Protection Act, the US may be close to doing away with DST switches, by adopting the DST time year-round.)

Is there a technical issue supporting non-UTC timezone pinning? No—it is certainly not impossible, but it is a non-trivial amount of work. We can discuss whether it should be prioritized over other features (before DST starts again in Spring), but in the meantime I was hoping to provide some educational material and workarounds.

I get that @emsearcy and do appreciate your efforts on education here. Like I said, it’s something that makes this meeting management tool different from what they are doing today in a more limited way. To your point it could be a moot one over time.

One thing we might want to do if the intention is to do meeting scheduling using UTC is have the tool work in UTC vs local time. See the image below - yes I do understand you have a bunch of disclaimers, but the natural flow for a user is to think “I scheduled a recurring meeting for 4pm every week, so it should be 4pm every week”.