Skip to content
Thirdlane

Time Zones

A phone system records everything in one instant of time but shows it to people in many places. A call that happened at 21:30 UTC happened at 14:30 for someone in Los Angeles and at 09:30 the next morning for someone in Auckland. All three describe the same moment. Which one a screen shows, or a voicemail announcement speaks, depends on the time zone that surface has been told to use.

This page explains where time zones are set, which screens and announcements each setting controls, and how the platform decides when more than one is set.

Why you would want to set them

Left alone, everything follows the server’s own clock. That is correct only for people who happen to be in the same zone as the server, which on a hosted platform is often nobody. The symptoms are easy to recognise:

  • A voicemail left at 2:45 in the afternoon is announced as “received at nine forty five PM”.
  • Call history shows calls that appear not to have happened yet.
  • Two people in the same office read the same message list and see different times, because their computers are set differently.

Setting the time zone for an organization, and letting individual people override it, makes every one of those surfaces agree.

Where a time zone can be set

There are three levels. Each one is optional, and each overrides the one above it.

  • Platform default - Communications Settings > Default Values, the Timezone field. Applies to everyone who has nothing more specific set.
  • Organization - Organizations, open the organization, the Timezone field. Applies to everyone in that organization.
  • Person - Personal Preferences in the User Portal, the Time Zone field. Applies to that one person, on every device they sign in from. An administrator can set the same thing for someone else on the Basic tab of their User Extension.

The platform uses the most specific one that is set: the person’s own choice if they made one, otherwise their organization’s, otherwise the platform default, otherwise the server clock.

Time zones are named the standard way, as a region and a city - America/Los_Angeles, Europe/Berlin, Australia/Sydney. Names like these carry their own daylight-saving rules, so a zone set once stays correct when the clocks change. A fixed offset such as UTC-8 would not; it would be an hour wrong for half the year.

What each surface uses

SurfaceTime zone used
Configuration Manager screensThe signed-in administrator’s, otherwise the organization’s
User PortalThe signed-in user’s, otherwise their organization’s
Thirdlane ConnectThe signed-in user’s, otherwise their organization’s
Call detail records and reportsThe organization’s
Voicemail spoken announcementThe mailbox owner’s, otherwise their organization’s
Voicemail notification emailThe mailbox owner’s, otherwise their organization’s

Connect and the User Portal show the same times as each other because the server resolves the zone once and both use the answer. Neither one follows the time zone of the computer or phone it is running on, so a user travelling with a laptop still sees times in their home zone until they change the setting.

Voicemail is different, and why

Every screen listed above is drawn by the Manager or by Connect, which know who is signed in. A voicemail announcement is spoken by Asterisk, the telephony engine, which does not - it knows only the mailbox. So a time zone for voicemail has to be recorded against the mailbox itself.

The platform does this for you. Whenever a timezone changes - a user’s, an organization’s, or the platform default - the affected mailboxes are updated to match, using the same order of precedence described above. There is nothing to run and nothing to reload; the change applies to the next message.

Two consequences worth knowing:

  • A mailbox never loses a hand-set value. If someone set a mailbox’s time zone directly in voicemail.conf, the platform leaves it alone.
  • Changing an organization’s time zone restamps its mailboxes, but only those that have not been given a more specific setting. A user who chose their own time zone keeps it.

Voicemail time format

Alongside the time zone there is a Voicemail time format setting, on the same three screens. It controls the clock used when voicemail speaks the time a message arrived:

  • Automatic - follows the convention of the country the time zone belongs to. A 12-hour clock for the United States, Canada, Australia and India; a 24-hour clock everywhere else. This is correct for nearly everyone, which is why it is the default.
  • 12 hour - “two forty five PM”.
  • 24 hour - “fourteen forty five”.

The notification email uses the same time zone but always writes a 12-hour clock.

How to set it up

For an organization whose people are all in one place:

  1. Open Organizations and select the organization.
  2. Set Timezone to the region and city where the organization is - for example America/Los_Angeles.
  3. Leave Voicemail time format on Automatic unless the organization has a stated preference.
  4. Save. Mailboxes are updated as part of the save.

For a platform where most organizations share a zone, set that zone once in Communications Settings > Default Values and then set Timezone only on the organizations that differ.

For an individual in a different place from their colleagues:

  1. Have them sign in to the User Portal and open Personal Preferences.
  2. Set Time Zone and save.

An administrator can do this without the user: open their User Extension, set Time Zone on the Basic tab, and save.

Their screens, their Connect client and their voicemail all follow the new setting; their colleagues are unaffected.

Checking it worked

  • Voicemail - leave a message on the mailbox and listen to the announcement. It should speak the local time where the mailbox owner is.
  • Notification email - the date line in the email should read the same local time.
  • Connect and the User Portal - open a recent call or message. The time shown should match the wall clock where the user is, whatever the computer is set to.
  • Reports - a report covering “today” runs against the organization’s day, not the server’s, so a report run late in the evening in a zone ahead of the server should still cover the local day.

An administrator screen can lag a change by up to ten minutes, because the resolved time zone is cached for that long. Voicemail and reports are not cached and change immediately.

Best practices

  • Set the platform default to the zone most of your customers are in. It removes the need to set anything on the majority of organizations.
  • Always use a region and city name, never a fixed offset, so daylight saving is handled for you.
  • Set the organization time zone before creating extensions. Mailboxes created afterwards pick it up when they are created, so there is nothing to correct later.
  • Leave the voicemail time format on Automatic unless someone asks for the other clock. The country convention is what callers expect to hear.
  • Change the server’s own clock only if you have a reason to. With time zones set per organization and per person, the server clock stops being visible to anyone, and moving it affects log files and scheduled jobs.