Timezone mismatch during outbound calls despite correct profile & Cal.com event settings

Support Help
1

Hi Retell team,

I’m facing a timezone mismatch issue while using Retell for outbound calling with Cal.com connected for meeting scheduling.

Setup:

  • Using a single-prompt agent

  • Agent is used for outbound calls

  • Cal.com is connected for meeting booking

  • Meetings are created successfully

Issue:
Even after setting the correct timezone everywhere, the agent still uses or refers to an incorrect timezone during the call or while confirming meeting times.

What I’ve already verified:

  • Retell profile timezone is correct

  • Retell event timezone is correct

  • Cal.com profile timezone is correct

  • Cal.com event type timezone is correct

Despite this, the spoken time / scheduled reference does not align with the expected timezone.

Questions:

  1. Does the single-prompt agent rely on any default/system timezone internally?

  2. Is there a specific place where timezone must be explicitly enforced for outbound agents?

  3. When using Cal.com, does Retell prioritize:

    • Agent timezone

    • Event timezone

    • Or timezone passed in the booking payload?

Happy to share call IDs, logs, or screenshots if needed.

Thanks in advance for the help.

— Anshul

2

The timezone mismatch issue you’re experiencing is a known challenge with Cal.com integration in Retell AI(1). The primary solution is to explicitly provide the current time in your desired timezone to your agent using dynamic variables(1).

Key Solution: Use Current Time Dynamic Variables

You need to tell the agent the current time for your specific timezone using the {{current_time_[timezone]}} variable format(1). For example, if you need Central Time, you would use {{current_time_America/Chicago}}(1).

When configuring your Retell LLM, you can set this in the default_dynamic_variables field(2):

{
  "default_dynamic_variables": {
    "customer_name": "John Doe"
  }
}

(2)

Cal.com Integration Configuration

When setting up the Cal.com appointment booking function, you can specify a timezone parameter(3). The function configuration includes(3):

{
  "type": "book_appointment_cal",
  "name": "book_appointment",
  "description": "Book an annual check up.",
  "cal_api_key": "cal_live_xxxxxxxxxxxx",
  "event_type_id": 60444,
  "timezone": "America/Los_Angeles"
}

(3)

Timezone Handling Approach

According to community reports, Cal.com doesn’t auto-detect timezone from area code, and you need to pass the correct timezone in the booking payload(4). The timezones in Cal.com and Retell must match for the booking features to work properly(5).

Prompt-Level Instructions

Include explicit timezone conversion instructions in your prompt(6). For example:

- **Convert today's date: `{{current_time}}` to Central Time (America/Chicago, CST/CDT) before making the request to ensure the requested time is not in the past.**
- **Check availability in Central Time (CST/CDT)** by calling function `check_availability_cal_3`.

(6)

The agent doesn’t automatically know the current time or timezone context without you explicitly providing it through dynamic variables(1). This is the most critical step to resolve your timezone mismatch issue.

**

3

Hello @Anshul_Soni

Can you share the call id and explain what timezone you want to use?

4

To help troubleshoot your timezone mismatch issue, you should explicitly provide the current time in your desired timezone using dynamic variables(1)(2).

Use the {{current_time_[timezone]}} variable format in your agent configuration(1)(2). For example, if you need Central Time, use {{current_time_America/Chicago}}(2).

When configuring your Cal.com appointment booking function, specify the timezone parameter(2):

{
  "type": "book_appointment_cal",
  "name": "book_appointment",
  "description": "Book an annual check up.",
  "cal_api_key": "cal_live_xxxxxxxxxxxx",
  "event_type_id": 60444,
  "timezone": "America/Los_Angeles"
}

(2)

You can also set default dynamic variables in your Retell LLM configuration(2):

{
  "default_dynamic_variables": {
    "customer_name": "John Doe"
  }
}

(2)

Sharing your call ID and specifying which timezone you want to use will help identify the exact issue.