How to build a world clock for an online team

Your community team may be online at the same time, but not at the same hour. A pinned list of local clocks helps moderators plan events, cover busy periods, and avoid asking someone to join at an unreasonable time.

Start with the places where team members actually live, then keep the list short enough to scan. The World Clock can show those local times together. This guide also explains how to label the clocks and handle daylight saving changes.

Build the team clock list

1. Open the World Clock and select the city or time zone for each main team location. Use a representative city when several people share a time zone.
2. Give each clock a useful label, such as “Support lead” or “West Coast moderators.” If the tool only displays city names, keep a separate key that connects each city to a team role.
3. Check the clock list at a time when your team normally works. Note who is online, who is near the start or end of their day, and whether any region is several hours ahead or behind.
4. Copy the locations and labels into a pinned team post or planning document. Include one time in UTC for event announcements, then state the intended local times for the main team regions.

For a small team, start with one clock per time zone, not one per person. If a community spans more regions, add clocks for the places that affect event attendance or moderation coverage. A list of five useful clocks is often easier to maintain than a long roster of every location.

Choose the right locations and labels

Several teammates share one time zone

Use one city as the representative clock, then label it with the relevant team members or role. For example, “New York, evening moderators” is more useful than a city name alone. If teammates are spread across a large region with multiple time zones, add another representative city for that region.

A city name is clearer than a fixed offset

Prefer a named city or time zone over labels such as UTC-5. A location-based zone follows that region's current rules, including daylight saving changes. A fixed offset does not change when local clocks move forward or backward, so it can become misleading for part of the year.

Too many clocks make the list harder to use

Keep the main view to the locations needed for planning and coverage. If a new member joins in a new region, add that location when it affects scheduling. You can keep a fuller roster in a separate document, but the pinned clock list should answer the quick question: “What time is it for the people I need to contact?”

Choose one display format

Use either a 12-hour or 24-hour format consistently in the team post. The 24-hour format can reduce ambiguity for international teams, while 12-hour time may be more familiar to some members. For help choosing a format, see how to switch a world clock between 12 and 24 hours.

Keep the clock accurate as the team changes

1. Check daylight saving dates. Regions do not all change their clocks on the same date, and some do not observe daylight saving time. Before a seasonal schedule change, compare the displayed local times again and update any pinned event times.
2. Update locations when roles move. When a moderator changes time zones, revise the label or add the new location. Remove clocks that no longer help the team make a scheduling or coverage decision.
3. Use automatic time settings on your own device. On Windows 11, open Settings › Time & language › Date & time and check that the time and time zone are set correctly. On macOS, open System Settings › General › Date & Time. These settings help your device show the correct local time, but they do not replace a shared team clock list.
4. Recheck an event after changing its date. Moving an event by a week or two can place it on the other side of a daylight saving change in one region. Recheck every listed local time instead of assuming the offset stayed the same.

Use UTC as the meeting anchor

For an event, publish a date and time in UTC along with a few local examples. UTC gives the team one shared reference that does not shift with seasonal clock changes. For instance, an announcement can include “18:00 UTC” followed by the local times for the regions most likely to attend. Check those conversions when you publish the announcement, especially near a daylight saving change.

Do not use an abbreviation such as EST or CST as the only time reference. The same abbreviation can refer to different regions, and some abbreviations describe standard time even when a location is observing daylight time. A city name plus its local time, or an explicit UTC time, is less ambiguous.

Use role labels rather than exact home addresses in a public community post. A representative city is usually enough for planning without revealing where a team member lives.