The Microsoft Teams 'ghost' time zone: Why Micro...

If you've ever had a user insist their computer is showing the correct time while Microsoft Teams insists they're unavailable until hours later, you've likely run into one of the more confusing Microsoft 365 scheduling issues.

The symptoms are consistent:

• Windows clock is correct
• Outlook Desktop shows correct local time
• Calendar behaves normally for the user
• Teams Scheduling Assistant shows the user in Pacific Time (UTC-8/UTC-7)
• Meetings appear incorrectly outside working hours

This creates the impression that a Microsoft 365 user is "in the wrong time zone," even when nothing on their machine appears misconfigured.

The root cause is usually not Windows. It is Exchange Online mailbox configuration.

The hidden disconnect

Exchange Online stores multiple time-related configurations that do not always stay aligned.

Two key settings:

Mailbox Regional Configuration (Get-MailboxRegionalConfiguration)

Controls the user's mailbox "personal view":

• Time zone
• Language
• Date format
• Time format

Mailbox Calendar Configuration (Get-MailboxCalendarConfiguration)

Controls scheduling behavior:

• Working days
• Working hours
• WorkingHoursTimeZone

These are independent values. When they align, scheduling behaves normally. When they diverge, Teams and Outlook Scheduling Assistant can display incorrect availability.

Why it often appears as Pacific Time

In some tenants, newly provisioned or uninitialized mailboxes appear to default to Pacific Time for calendar working hours.

Microsoft does not clearly document this as a "default," but it is a consistent observation across environments where:

• Mailboxes are created but never fully initialized interactively
• Users never log into Outlook on the web
• Settings are never explicitly set during provisioning

As a result, the mailbox retains a working-hours time zone that does not match the user's actual location.

Why only certain users are affected

This issue is most visible in environments with:

• Shared PCs
• Floating workstations
• Users who only use Outlook Desktop
• Minimal use of Outlook on the web

Outlook Desktop relies heavily on the local Windows time zone, which masks backend inconsistencies.

The issue only appears when another user schedules against the affected mailbox.

Example:

• User works in Central Time
• Exchange mailbox still shows WorkingHoursTimeZone = Pacific
• Scheduling Assistant shifts availability two hours earlier

Result:

"Teams says I'm unavailable, but I'm sitting at my desk."

Don't forget conference rooms

User mailboxes are not the only affected objects. Conference room mailboxes can experience the same mismatch.

In fact, they are often more likely to be affected.

Room mailboxes are rarely (if ever) logged into interactively. If mailbox initialization depends on first-time login or explicit configuration, the room may remain in a default or inconsistent state indefinitely.

Symptoms include:

• Rooms appearing unavailable during business hours
• Incorrect free/busy calculations
• Scheduling Assistant showing unexpected availability

When auditing, always include room mailboxes alongside user mailboxes.

After all, a conference room can't submit a helpdesk ticket when it's living in California.

Why the issue goes undetected

This problem can exist at scale without obvious symptoms.

Reasons include:

• Outlook Desktop masks backend time zone differences
• Users rarely inspect mailbox-level configuration
• Misconfigured mailboxes may still align with each other
• The issue only surfaces in cross-configuration scheduling scenarios

As a result, environments can have widespread misalignment without obvious user impact until specific scheduling conflicts occur.

Auditing your tenant

To identify mismatched mailboxes:

Connect-ExchangeOnline

$Mailboxes = Get-Mailbox -ResultSize Unlimited -RecipientTypeDetails UserMailbox,RoomMailbox

$Report = foreach ($Mailbox in $Mailboxes) {

$Identity = $Mailbox.PrimarySmtpAddress

$Calendar = Get-MailboxCalendarConfiguration -Identity $Identity
$Regional = Get-MailboxRegionalConfiguration -Identity $Identity

[PSCustomObject]@{
DisplayName = $Mailbox.DisplayName
MailboxType = $Mailbox.RecipientTypeDetails
Email = $Mailbox.PrimarySmtpAddress
CalendarZone = $Calendar.WorkingHoursTimeZone
RegionalZone = $Regional.TimeZone
}
}

$Report | Format-Table -AutoSize

To isolate mismatches:

$Report | Where-Object {
$_.CalendarZone -ne $_.RegionalZone
} | Format-Table -AutoSize

Correcting the configuration

For organizations operating in a single time zone, standardizing mailbox settings can resolve inconsistencies.

Example for Central Time:

Connect-ExchangeOnline

$Mailboxes = Get-Mailbox -ResultSize Unlimited -RecipientTypeDetails UserMailbox,RoomMailbox

foreach ($Mailbox in $Mailboxes) {

$Identity = $Mailbox.PrimarySmtpAddress

Write-Host "Updating $Identity..."

Set-MailboxCalendarConfiguration `
-Identity $Identity `
-WorkingHoursTimeZone "Central Standard Time"

Set-MailboxRegionalConfiguration `
-Identity $Identity `
-TimeZone "Central Standard Time"
}

For multi-time-zone organizations, settings should match the user's actual location rather than applying a single global value.

Preventing the problem

The most reliable fix is prevention.

During user and room mailbox provisioning, explicitly set:

• Regional configuration
• Calendar configuration

This avoids relying on implicit initialization behavior that may not occur consistently across clients.

Allow time for propagation

Exchange updates apply quickly, but Teams caching introduces delay.

Typical behavior:

• Exchange update: immediate
• Outlook visibility: minutes to hours
• Teams Scheduling Assistant: up to 24 hours in some cases

Conclusion

This issue is difficult to diagnose because all systems appear correct individually:

• Windows time is correct
• Outlook appears correct
• Exchange data exists
• Teams reflects Exchange data accurately

The problem arises when mailbox regional configuration and calendar working-hours configuration diverge.

Once aligned, the "California time zone" effect disappears, and scheduling behavior becomes consistent across Teams and Outlook.

If users report that Microsoft Teams thinks they are in the "wrong time zone," the issue is often not the client-it is mailbox configuration.

And don't forget to check the conference rooms. They may have been quietly operating on Pacific Time all along.