Critical Issue: Inconsistent Timezone Handling in ...
# supportc
Chete
05/29/2025, 5:28 AMDear VAPI Support Team,
I am writing to report an ongoing and critical issue affecting the google_calendar_check_availability_tool, which is currently producing inconsistent timezone handling and mismatched time intervals between the request (tool_call) and the response (tool_call_result). This makes it unreliable for scheduling availability slots.
⸻
🧪 Example 1 – Call ID: ecbd4161-9e1f-49b0-8e90-73ee2d38eea5
Request:
{
"startDateTime": "2025-06-03T17:30:00+02:00",
"endDateTime": "2025-06-03T18:00:00+02:00",
"timeZone": "Europe/Madrid"
}
Result:
{
"busy": [],
"free": [
{
"start": "2025-06-03T15:30:00.000Z",
"end": "2025-06-03T16:00:00.000Z"
}
]
}
🔴 Problems:
• Response is in UTC (Z), not in the requested +02:00.
• The returned interval (15:30–16:00 UTC) does not correspond to the requested range (17:30–18:00 CEST).
⸻
🧪 Example 2 – Call ID: d9ef775a-b435-4c54-9d13-34b2cb1bed6d
Request:
{
"startDateTime": "2025-06-03T18:00:00+02:00",
"endDateTime": "2025-06-03T18:30:00+02:00",
"timeZone": "Europe/Madrid"
}
Result:
{
"busy": [],
"free": [
{
"start": "2025-06-03T16:00:00.000Z",
"end": "2025-06-03T16:30:00.000Z"
}
]
}
🔴 Problems:
• Times are again returned in UTC instead of +02:00.
• The interval does not match the time range queried.
Chete
05/29/2025, 5:29 AM🧪 Example 3 – Call ID: 8d2b69cb-c48e-4157-a0ee-0501e4a2e36c
🟦 Request:
{
"startDateTime": "2025-05-29T10:00:00+02:00",
"endDateTime": "2025-05-29T14:00:00+02:00",
"timeZone": "Europe/Madrid"
}
🟩 Result:
{
"busy": [
{
"start": "2025-05-29T10:30:00+02:00",
"end": "2025-05-29T11:30:00+02:00"
}
],
"free": [
{
"start": "2025-05-29T08:00:00.000Z",
"end": "2025-05-29T10:30:00+02:00"
},
{
"start": "2025-05-29T11:30:00+02:00",
"end": "2025-05-29T12:00:00.000Z"
}
]
}
⸻
❌ Problems:
1. Mixed timezones in the same response:
• The first free interval uses UTC (08:00.000Z) for the start,
• but ends in local time (10:30+02:00).
• This inconsistency breaks logic that expects homogeneous formats.
2. Ambiguity and parsing risk:
• Interpreting 08:00Z requires conversion to 10:00+02:00, but that’s not explicit—creates potential misalignment or duplication when visualizing intervals.
3. Overlapping or invalid interval:
• The second free block ends at 12:00:00.000Z, which equals 14:00+02:00, but it follows a start time of 11:30+02:00.
• This inconsistency suggests either:
• a misordered interval, or
• a backend formatting bug, since the end time appears to precede the start time when converted to a common zone.
c
Chiranjeet Mishra
05/30/2025, 5:46 AMHey Chete, thanks for sharing these call_ids. Let me do my review and get back to you.
c
Chete
05/30/2025, 11:13 AMOk Thanks
Chete
05/30/2025, 11:14 AMTell me ASAP
c
Chiranjeet Mishra
05/31/2025, 1:06 AMThere was a fix deployed for this issue on the 27th, which was when these calls were made. Could you test it again and let us know if the issue is still occurring?
c
Chete
05/31/2025, 6:42 PMHi Kyle
Thanks for the follow-up. I understand a fix was deployed on the 27th, however, I’ve tested the tool again several times after that date, and the issue with inconsistent timezone formatting is still present.
Here are two new examples for your review:
First Call
Call ID: 4ffbcd6a-7bc3-4dc3-988e-3e85fe7c7a1b
Request:
{
"startDateTime": "2025-06-04T10:00:00+02:00",
"endDateTime": "2025-06-04T14:00:00+02:00",
"timeZone": "Europe/Madrid"
}
Response (free slots):
[
{
"start": "2025-06-04T10:30:00+02:00",
"end": "2025-06-04T11:00:00+02:00"
},
{
"start": "2025-06-04T12:00:00+02:00",
"end": "2025-06-04T13:00:00+02:00"
},
{
"start": "2025-06-04T13:30:00+02:00",
"end": "2025-06-04T12:00:00.000Z"
}
]
Problem: As you can see, the last interval mixes timezones within the same object (start in +02:00 and end in Z), which breaks the logic of availability calculation and makes the slot invalid.
Second Call
Call ID: b6deb5aa-4076-49da-a986-d729ae8c5cf8
Request:
{
"startDateTime": "2025-06-04T17:30:00+02:00",
"endDateTime": "2025-06-04T20:30:00+02:00",
"timeZone": "Europe/Madrid"
}
Response (free slots):
[
{
"start": "2025-06-04T15:30:00.000Z",
"end": "2025-06-04T18:00:00+02:00"
},
{
"start": "2025-06-04T18:30:00+02:00",
"end": "2025-06-04T18:30:00.000Z"
}
]
Problem: Again, the free slots returned use a mix of UTC (Z) and local +02:00 timezones, which is inconsistent with the request and impossible to interpret reliably.
Expected Behavior:
The tool should return all start and end times in the same timezone as requested, in this case, Europe/Madrid (+02:00), for all availability intervals.
Best regards
Chete
05/31/2025, 6:44 PMHere you are 2 examples: the morning shift and the afternoon shift is when my clients operate
Chete
06/02/2025, 6:28 AMHi team,
Just following up on my previous message regarding the inconsistent timezone handling in the google_calendar_check_availability_tool.
As shown in the examples I shared (calls with IDs 4ffbcd6a-7bc3-4dc3-988e-3e85fe7c7a1b and b6deb5aa-4076-49da-a986-d729ae8c5cf8), the issue still persists, mixing UTC and Europe/Madrid times in the same tool_call_result.
Could you please confirm whether a permanent fix is on the way or if there’s a recommended workaround?
Looking forward to your reply.
Best regards,
Ignacio de Diego
Chete
06/02/2025, 10:22 PMI’m writing again to express my concern regarding the lack of response to the messages I’ve sent over the past few days — both via email and through the platform. As of now, I have not received any update, acknowledgment, or resolution.
This issue with the google_calendar_check_availability_tool is critically affecting our assistant’s functionality, and we’ve already provided multiple examples demonstrating inconsistent behavior and timezone mismatches. It is blocking further deployment and causing unnecessary complications in user interactions.
I kindly ask you to respond as soon as possible. At this point, I would appreciate at least a confirmation that the problem has been escalated or is being reviewed by your technical team.
Looking forward to your reply.
Best regards,
c
Chiranjeet Mishra
06/03/2025, 12:21 AMWe apologize that this issue is still occurring. We will reach out to our development team and have them review these call ids that you have provided. In the meantime, could you provide the update channel that your account is using? You can find this info on the dashboard under the org settings. It should be either weekly or daily channel.
c
Chete
06/03/2025, 6:43 AMI changed it from weekly to daily and still worked wrong, so I don’t think that is the problem
c
Chiranjeet Mishra
06/03/2025, 9:01 PMCould you please make another test call and provide the call id if the tool fails? We will use this information to further escalate to our dev team.
c
Chete
06/03/2025, 10:50 PMHey Kile I have tested again and it fails
Chete
06/03/2025, 10:50 PMThe tool id is : The call id, is: cb71b826-a101-46ee-bea2-eb75267a7657
Chete
06/04/2025, 8:21 AMOkey, please take into account this:
Just to clarify something that might be causing confusion:
When the tool returns a time like 2025-06-03T12:00:00.000Z, that means 12:00 noon in UTC (Zulu time).
However, since my organization and calendars are operating in the Europe/Madrid time zone (which is UTC+2 during summer), that same timestamp actually corresponds to:
2025-06-03T14:00:00+02:00
In other words, 12:00Z = 14:00 in Europe/Madrid — they’re the same point in time, just expressed in different time zones.
The problem seems to be that the system does not interpret this equivalence properly when checking availability. From what I’ve seen, it only works correctly when the ToolCall input and the ToolCallResult are returned in the same timezone format (+02:00), even though the times themselves are technically aligned.
Let me know if this makes sense — I suspect this mismatch in timezone interpretation is at the root of the issue.
c
Chiranjeet Mishra
06/05/2025, 3:40 PMHey Chete,
The core problem is in the calculateFreeSlots function. Here's what's happening:
• The busySlotsRaw comes directly from Google Calendar API (which returns UTC timestamps)
• The calculateFreeSlots our function processes these raw slots but doesn't consistently convert all boundary calculations to the same timezone format
• This creates a mismatch where some free slot boundaries are in UTC and others are in the local timezone
The issue stems from mixing timezone-aware DateTime objects with raw Google Calendar API responses that may be in different timezone formats, causing the availability calculations to produce inconsistent results.
I am reporting this to the team to get it fixed.
c
Chete
06/05/2025, 8:07 PMPerfect shubham I am glad to know that We are in the Same point
Chete
06/09/2025, 4:25 PMHi Shubham,
I wanted to follow up again — it’s now been 4 days since your last message and I still haven’t received any update on the status of the fix for the timezone inconsistency in the calendar availability tool.
As I explained, this issue is currently blocking us from moving forward. I need to know whether this is actively being addressed and if there is an expected resolution date.
I would appreciate your reply as soon as possible — this is becoming very urgent on my side.
Best regards,
Ignacio de Diego
c
Chiranjeet Mishra
06/09/2025, 9:27 PMHey Chete, the issue is still open with us and it will be resolved by end of this week for sure.