https://retellai.com/?utm_source=discord&utm_medium=seo logo
Powered by
t
@AI Evy i'm using cal.com to get bookings but there is a +11:00 that keeps appearing on the start and end times of the tool call so it's not working. how do i fix this? https://cdn.discordapp.com/attachments/1302816169367044149/1457963942524616714/image.png?ex=695dea3b&is=695c98bb&hm=853753580d7ff2dd3fb9ddc89af77baf6a77260b8972ff2b76fb7254627336bf&
a
Thanks for tagging me @teppie. I'll look through relevant sources and get back to you shortly.
### Answer The 
+11:00
offset appearing in your Cal.com booking times indicates a timezone mismatch. Based on similar issues reported, here are the key fixes: 1. Ensure timezones match between Retell and Cal.com [(1) ]() The timezone configured in your Retell Cal.com function should match the timezone set in your Cal.com calendar. 2. Use the 
{{current_time}}
variable before triggering calendar functions Include 
{{current_time}}
in your prompt before both the availability check and booking functions. This tells the AI the current date and time so it can convert timezones accordingly. 3. Ask for the user's timezone before checking availability and booking 4. Set the timezone explicitly in your booking function The Cal.com booking tool supports a 
timezone
parameter: [(2) ]()
Copy code
json
{
  "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"
}
Make sure the 
timezone
field is set to the correct timezone for your use case (e.g., 
Australia/Sydney
if you're seeing 
+11:00
) .
​ To learn more, see the sources I considered: [[1] Urgent: Cal.com Booked on different day - Potential Service Disruption with multiple issue.](https://discord.com/channels/1186424376300679209/1423174290458808381) [[2] Get Retell LLM](https://docs.retellai.com/api-references/get-retell-llm) ​
Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.
t
hello @User i added that and it didn't fix the problem. what helped was to add a node that transforms the time format, but it's not consistently working. this is my prompt for the node: Instructions: 1. Say a filler: "One moment" OR "Okay" 2. Slowly repeat the date/time naturally: "Friday 9AM, that's January 10th" 3. Ask: "Did I hear that right?" OR "Is that correct?" 4. SILENTLY format as: YYYY-MM-DD HH:mm:ss (no timezone offsets) 5. Do NOT say the formatted version aloud (no "09:00:00 hours minutes") but remember it for the next node 6. Wait for a response, update if there are corrections. Examples: Say: "Okay... Friday 9AM, January 10th. Does that work?" Format: "2024-01-10 09:00:00 hours minutes seconds" Format: 2024-12-18 14:30:00 (NOT 2024-12-18T14:30:00+11:00) let me know what works https://cdn.discordapp.com/attachments/1457963942763696342/1458306955344089263/image.png?ex=695f29b0&is=695dd830&hm=1d722573b8873aa94a08507849f8509863e291b42132448a23d0d9ee450648cf& https://cdn.discordapp.com/attachments/1457963942763696342/1458306955637428408/image.png?ex=695f29b0&is=695dd830&hm=81dd9fc591be4705b2a9466e9d80fece6eacc827788e59c47637b42c6d9906bd&
a
Appreciate the feedback! Feel free to ask me again with additional guidance or context.
Thanks for the follow-up, @teppie. I'll get back to you soon.
t
hello @AI Evy i added that and it didn't fix the problem. what helped was to add a node that transforms the time format, but it's not consistently working. this is my prompt for the node: Instructions: Say a filler: "One moment" OR "Okay", Slowly repeat the date/time naturally: "Friday 9AM, that's January 10th", Ask: "Did I hear that right?" OR "Is that correct?", SILENTLY format as: YYYY-MM-DD HH:mm:ss (no timezone offsets), Do NOT say the formatted version aloud (no "09:00:00 hours minutes") but remember it for the next node, Wait for a response, update if there are corrections., Examples: Say: "Okay... Friday 9AM, January 10th. Does that work?" Format: "2024-01-10 09:00:00 hours minutes seconds" Format: 2024-12-18 14:30:00 (NOT 2024-12-18T14:30:00+11:00) let me know what works
a
### Answer --- Based on your logs showing 
+11:00
offsets, the issue is that your timezone is set to 
Australia/Sydney
(which is GMT+11) , and this offset is being appended to your times. [(1) ]() Key fixes to try: 1. Remove the timezone from your Cal.com function configuration - A community member confirmed that removing the timezone setting resolved similar issues. 2. Ensure timezone consistency - Your Cal.com account timezone settings must match what you configure in the Retell function. When adding the Cal.com function in Retell, you can optionally add a timezone to be used in the function. [(2) ]() , [(3) ]() 3. Use the v1 API if building custom functions - Community feedback indicates the Cal.com v2 API provides outputs in UTC only, while v1 handles timezones better. One user reported success using ` [(4) ]() 4. Have the agent say the booking time out loud - You mentioned it only works when the agent says the time aloud. This is a known workaround that has helped others. [(1) ]() Regarding your prompt approach to format times without timezone offsets - this is creative but unreliable because the LLM may still pass timezone-aware formats to the underlying Cal.com API. The timezone handling happens at the API level, not just in how the agent speaks. I'd recommend first verifying your timezone is set correctly in both your Cal.com dashboard and in the Retell Cal.com function configuration. [(2) ]() , [(3) ](
ck-availability)
​ To learn more, see the sources I considered: [[1] Cal.com Time Booking issues](https://discord.com/channels/1186424376300679209/1457994519529132186) [[2] Book Calendar](https://docs.retellai.com/build/book-calendar) [[3] Check Calendar Availability](https://docs.retellai.com/build/check-availability) [[4] Discord message from @sanava.ai on 2024-11-06](https://discord.com/channels/1186424376300679209/1294891368505937952/1303839190676537379) ​
Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.
t
@AI Evy we would need Retell to support the format with the +11 because the AI alternates between with and without it regardless of prompt instructions. we've tested it multiple times and can now confirm the +11 appears randomly, and when it does, our bookings don't come through.
a
Thanks for the follow-up, @teppie. I'll get back to you soon.
### Answer --- I understand the frustration—you've confirmed that the 
+11:00
timezone offset appears inconsistently regardless of prompt instructions, causing bookings to fail. Based on the available documentation, the Cal.com booking function supports an optional 
timezone
parameter that you can configure when adding the function. [(1) ]()
Copy code
json
{
  "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) ]() The documentation also notes to "make sure to configure the correct time zone settings on both the Cal.com platform and the Retell AI dashboard for accurate scheduling." [(3) ]() However, I don't have documentation that addresses the specific issue of the LLM inconsistently adding timezone offsets to the time format, or a way to force a specific datetime format at the API level. This sounds like a feature request or potential bug that would need to be raised directly with the Retell team. I'd recommend reaching out through: - [Contact Sales]() - [GitHub]() They would be best positioned to address whether Retell can normalize datetime formats before passing them to Cal.com, regardless of how the LLM outputs them.
​ To learn more, see the sources I considered: [[1] Book Calendar](https://docs.retellai.com/build/book-calendar) [[2] Get Retell LLM](https://docs.retellai.com/api-references/get-retell-llm) [[3] AI Appointment Scheduling with Voice AI Booking Assistant](https://www.retellai.com/features/book-appointments) ​
Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.
t
hi @AI Evy are you able to deduce the cause of this bug?
a
Thanks for the follow-up, @teppie. I'll get back to you soon.
### Answer Based on the available documentation, I cannot definitively identify the root cause of this bug. Here's what the documentation shows: The Cal.com booking function accepts an optional 
timezone
parameter when configured: [(1) ]()
Copy code
json
{
  "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) ]() The documentation doesn't explain how the LLM formats datetime values before passing them to the Cal.com API, nor does it address why the 
+11:00
offset would appear inconsistently. [(1) ]() , [(3) ]() A community member noted that the Cal.com v2 API "provides outputs in utc only" while v1 handles timezones differently—using ` worked for them. [(4) ]() What I can confirm: - The timezone parameter is optional in the function configuration [(1) ]() , [(3) ]() - There's no documented mechanism to force a specific datetime format at the API level What this likely indicates: The inconsistency suggests the LLM is variably formatting datetime strings before they reach the Cal.com API. This appears to be a gap between how the LLM generates datetime values and what format Cal.com expects—something that would need to be addressed at the platform level. I'd recommend raising this directly with the Retell team via [Contact Sales]() or [GitHub]() .
​ To learn more, see the sources I considered: [[1] Book Calendar](https://docs.retellai.com/build/book-calendar) [[2] Create Retell LLM](https://docs.retellai.com/api-references/create-retell-llm) [[3] Check Calendar Availability](https://docs.retellai.com/build/check-availability) [[4] Discord message from @sanava.ai on 2024-11-06](https://discord.com/channels/1186424376300679209/1294891368505937952/1303839533699170424) ​
Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.
PreviousNext
Powered by