Cal.com booking from api, timezone is not being applied from api v2.

[samyogdhital]

I made a cal.com request to this api
https://api.cal.com/v2/bookings

with this payload

{
"start": "2025-06-03T13:00:00.000Z",
"attendee": {
"name": "Rajesh",
"email": "[email protected]",
"timeZone": "Asia/Katmandu",
"language": "en"
},
"eventTypeSlug": "30min",
"username": "samyog",
"bookingFieldsResponses": {
"title": "Integrating AI in business",
"notes": "Please let's do it fast."
},
"location": {
"type": "integration",
"integration": "google-meet"
}
}

see clearly the timezone is asia kathmandu right?
when I do the booking the api status is success but the time the meeting is booked is at Tue, 3 Jun
6:45pm - 7:15pm showing the dashboard. Why is that? And bookings done from the embedding is accurately giving the exact time the buttons were clicked and on dashbaorod app also showing the correct one.

What is the problem here? And are you 100% sure about that?
@dosu

[dosubot[bot]]

You're correct that your payload specifies the attendee's timezone as "Asia/Katmandu", and the API v2 endpoint expects the start time in UTC. According to the Cal.com API v2 implementation, the system processes the booking by converting the provided UTC start time to the attendee's timezone using the Luxon library: it does this with DateTime.fromISO(inputBooking.start, { zone: "utc" }).setZone(inputBooking.attendee.timeZone) (source). This means the time shown to the attendee should reflect the correct local time for "Asia/Katmandu".

However, the time you see on the dashboard (6:45pm - 7:15pm) does not match the expected conversion from your UTC input (2025-06-03T13:00:00.000Z should be 6:45pm in Kathmandu, which is UTC+5:45). This suggests the conversion is technically correct, but the experience differs between API bookings and bookings made via the embed.

The key difference is that the embedding feature passes the timezone as a query parameter (cal.tz) and manages it in the booking UI state, ensuring the user's selection is always respected in the UI (source). The API, on the other hand, relies entirely on the UTC start value you provide and the timeZone field for conversion at booking creation time.

If the time is correct in the dashboard for embed bookings but not for API bookings, double-check that the UTC start value you send to the API matches the local time you intend in "Asia/Katmandu". For example, if you want the meeting at 1:00pm local time in Kathmandu, you should convert that to UTC (07:15:00.000Z) before sending it in the payload. The API does not convert from local time to UTC for you—it expects UTC.

There are no open issues or recent changes in the codebase indicating a bug with the "Asia/Katmandu" timezone specifically, and the API validates that the timezone is a valid IANA identifier (source). The observed behavior is consistent with the API's design.

In summary:

• The API expects the start time in UTC, not local time.
• The timeZone field is used for display/context, not for converting local time to UTC.
• The embed UI handles local time selection and converts it to UTC before sending to the backend, which is why it "just works" from the user's perspective.

If you want a meeting at 1:00pm Kathmandu time, convert that to UTC (07:15:00.000Z) and use that as your start value in the API request. If you already did this and still see a mismatch, let me know the exact local time you intended and the UTC value you sent, and I can help debug further.

To reply, just mention my name @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[dosubot[bot]]

In a Next.js project, you should use ES6 imports instead of require. Here’s how to configure Day.js with timezone and UTC plugins:

import dayjs from 'dayjs';
import utc from 'dayjs/plugin/utc';
import timezone from 'dayjs/plugin/timezone';

dayjs.extend(utc);
dayjs.extend(timezone);

To get the local date and time as a single string in JavaScript, you can use:

const localDateTime = dayjs().format('YYYY-MM-DDTHH:mm:ss');

To convert a local date and time in a specific timezone to a UTC ISO string (which is what Cal.com API expects), use this one-liner (assuming you have a date/time string and a timezone):

const utcISO = dayjs.tz('2025-06-03T13:00:00', 'Asia/Katmandu').utc().toISOString();

Replace '2025-06-03T13:00:00' and 'Asia/Katmandu' with your actual values.

For best compatibility with Day.js and Cal.com, ask your AI model to return the date and time in this combined format:
YYYY-MM-DDTHH:mm:ss (for example: 2025-06-03T13:00:00).

You can give this description to your LLM:
"Return the date and time in a single string in the format YYYY-MM-DDTHH:mm:ss (for example: 2025-06-03T13:00:00)."

Then, use the code above to convert it to the UTC ISO string required for Cal.com API calls. This ensures your booking time is always correct, regardless of the user's or attendee's timezone.

To reply, just mention my name @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[samyogdhital]

@dosu start: dayjs.tz(startDateTime, Intl.DateTimeFormat().resolvedOptions().timeZone).utc().toISOString(),

is this correct or not? Or I don't have to give timezone value? What will be the default one?

And if I do this is this the good way to give timezone?

[dosubot[bot]]

Your code

start: dayjs.tz(startDateTime, Intl.DateTimeFormat().resolvedOptions().timeZone).utc().toISOString()

is technically correct if your goal is to convert a local date/time string (e.g., "2025-06-03T13:00:00") in the user's current browser timezone to a UTC ISO string for the Cal.com API.

Intl.DateTimeFormat().resolvedOptions().timeZone gives you the browser's detected timezone, which is a reasonable default for client-side apps when you don't have a more explicit timezone from the user. This is how Cal.com sets the default timezone in some UI forms if none is provided (source).

However, for API calls, it's best to be explicit: always use the actual intended timezone for the booking (for example, the attendee's timezone, or the timezone selected by the user in your UI). Relying on the browser's detected timezone is fine for interactive apps, but not robust for server-side or automated scenarios.

If you do not provide a timezone, Cal.com may default to 'Europe/London' in some backend logic (source), but this is not guaranteed everywhere. For unambiguous results, always specify the timezone explicitly.

In summary: your approach works for most client-side cases, but for best accuracy and portability, always pass the intended timezone string directly rather than relying on the browser default. If you omit the timezone, the default may be 'Europe/London', but this is not universal across all endpoints.

To reply, just mention my name @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[samyogdhital]

@dosu another question,

for checking availablilty slot, i am letting AI model do this tool call.

{
name: 'tool_to_get_booking_availability_slots_from_our_agency_calendar',
description: Gets the available timeslots for the user to book a free strategy meeting with our 100xVoice agency. This function gets all the available time slots between given startDate and endDate in given user's timezone time.,
parameters: {
type: SchemaType.OBJECT,
properties: {
startDate: {
type: SchemaType.STRING,
description: The start date . If user requests a past date as startDate, inform the user and have startDate as ${dayjs().utc().toISOString()},
},
endDate: {
type: SchemaType.STRING,
description: The end date in ISO string format. Must be minimum 5 hours after current time and date ${dayjs().utc().toISOString()}.,
},
timeZone: {
type: SchemaType.STRING,
description: The timezone to show the available slots to book in user's local time. By default from user's browser it is ${Intl.DateTimeFormat().resolvedOptions().timeZone}. Its nice to confirm the location from user.,
},
},
required: ['startDate', 'endDate', 'timeZone'],
},
},

  so here i have changed that new Date().toISOString() to this dayjs().utc().toISOString() one. Is it perfect?
  
  This is the actual implemenation with tool call for this booking slot api.
  
            const { startDate, endDate, timeZone = 'Asia/Katmandu' } = fCall.args as any;

            console.log(fCall.args, "tool_to_get_booking_availability_slots_from_our_agency_calendar")

            // Validate date inputs
            if (!startDate || !endDate) {
              functionResponse = {
                id: fCall.id,
                name: fCall.name,
                response: {
                  result: {
                    string_value: 'Please provide both start and end dates to check availability.',
                  },
                },
              };
              break;
            }

            // Get current date in YYYY-MM-DD format
            const currentDate = dayjs().utc().toISOString().split('T')[0];

            // Use current date if start date is in the past
            const effectiveStartDate = startDate < currentDate ? currentDate : startDate;

            // Convert dates to ISO format with time


            // Construct the API URL
            const apiUrl = new URL('https://api.cal.com/v1/slots');
            apiUrl.searchParams.append('apiKey', "cal_live_13262a24b7bcbf712068bb4bd24e76b9");
            apiUrl.searchParams.append('eventTypeId', "2113046");
            apiUrl.searchParams.append('startTime', startDate);
            apiUrl.searchParams.append('endTime', endDate);
            apiUrl.searchParams.append('timeZone', timeZone);

            const response = await fetch(apiUrl.toString(), {
              method: 'GET',
              headers: {
                'Accept': 'application/json'
              }
            });

            if (!response.ok) {
              throw new Error(`Failed to fetch slots: ${response.statusText}`);
            }

            const data = await response.json();

            // Format the response for the model
            functionResponse = {
              id: fCall.id,
              name: fCall.name,
              response: {
                result: {
                  string_value: JSON.stringify(data),
                },
              },
            };

            break;
          }
          
          So I think the way I'm handling time with this exact tool call I think it is not correct right previously I was using javascript's nativedate api and you already mentioned that that it has issues with daylight saving and some other issues right and that's why you recommended me to use djs which I did right on previous day js, Which I did actually in the previous tool call right for that booking call one right but for this getting the time slot with all the available time slots between between two given dates given to date and time is it that it also expects both start date and end date in utc format if that is then how should I give the model do I have to format anything or yeah how should I give the value is it the same that should I ask the model to literally give me string version of iso format right with the current time I as a format or I should include the current ISO time format in the description again the problem I'm trying to understand here is I think I'm not able to explain it well enough but the problem is that previously I was facing just like the booking problem where I book with a time on api and the time was not the exact time when I looked at the dashboard right but booking from the inline embed it was working like the exact time that I choose on embed I was getting that exact time on dashboard as well and the problem is facing steel right now is if I check for the slots if I check for the slots between a start I start time and date and end time and date what I was getting was I was asking the api to give me the slots from 3:15 onwards right II had done one thing to check to check the api I did a 30 minute booking from 315 to 345 right and I intentionally asked the slot api to give me the time available from 315 to the entire end of the day right 12:00 PM or 11:59 PM or something what I was getting was I was literally getting the slots from 9:00 PM or something I don't know 7:00 PM or 9:00 PM but in reality I only booked the meeting or it is the calendar was booked between 315 and 235 that's it 456 all all all all these hours were completely open but I don't know why I was getting that I think the problem is similar to that aboard right now how should I fix it and the way I'm implementing api right you have to look at that as well so one thing is I'm using version 1 api is there any version 2 api version of this for individual user right i'm not team user okay i'm individual user is there any version to api for this if yes then awesome let's implement that if not at least what you need to help me is zero to help me fix this time problem yeah you know to help me fix this time problem i'm trying to I'm trying to ask the model I'm trying to ask the model to write the model is simply a voice isn't that agent that ask the user and understands the user's query and as explained as as as as needed will book a meeting with the user right before booking it will look for the available slots and the problem was happening there like the slots say at 7:15 PM the slots is available but when I book it was not booking at that time I think we fixed that but still the slots are also not coming at the exact time I think we need to fix that as well so what I was saying to the ai model was let's say if a user gives the start date as past time and date then now then right now I was telling the model to literally have the start date as now ok and and for that I was using that date api now what should I do what should I do for how should I tell the model to give me the start and end date response because model doesn't know about daylight saving issues and things like that right it will literally give me the time the user tells me so I need to make sure that the format I'm getting or at least I'm passing to the slot api is exactly to the time exactly the way the model is wanting so that's why for the start date and time and end date and time how should I ask the model to give me the data right that the user asks say user says schedule a meeting or check check if the meeting slot is available at 10:00 PM.
          
          Help me do this.

[dosubot[bot]]

You're on the right track using Day.js for time handling, but there are a few key points to ensure your slot availability checks and bookings work as expected:

1. API expects UTC: Both the start and end times for the slots API should be in UTC ISO8601 format (e.g., 2025-06-03T07:15:00.000Z). The timeZone parameter is for display/context only and does not affect the slot search logic.

2. How to ask your AI model: Instruct your model to return date and time as a single string in the format YYYY-MM-DDTHH:mm:ss (e.g., 2025-06-03T13:00:00). This makes it easy to convert to UTC using Day.js.

   Example prompt for your LLM:

   Return the date and time in a single string in the format YYYY-MM-DDTHH:mm:ss (for example: 2025-06-03T13:00:00).
   

3. Convert to UTC for API: When you receive the date/time string and the user's timezone, convert it to UTC before sending to the API:

   import dayjs from 'dayjs';
   import utc from 'dayjs/plugin/utc';
   import timezone from 'dayjs/plugin/timezone';
   dayjs.extend(utc);
   dayjs.extend(timezone);
   
   const localDateTime = '2025-06-03T13:00:00'; // from AI model
   const timeZone = 'Asia/Katmandu'; // from user or browser
   const utcISO = dayjs.tz(localDateTime, timeZone).utc().toISOString();

   Use utcISO for your startTime or endTime in the API call.

4. Slot API v2 is available: There is a version 2 slots API you can use as an individual user. See the /v2/slots/available endpoint. You can query by eventTypeId or by eventTypeSlug and username. Example:

   GET https://api.cal.com/v2/slots/available?startTime=2025-06-03T07:15:00.000Z&endTime=2025-06-03T17:15:00.000Z&eventTypeId=2113046&timeZone=Asia/Katmandu
   

   Reference, Reference

5. Common slot API gotcha: If you want all slots for a single day, set endTime to the next day (e.g., startTime=2025-06-03T00:00:00Z&endTime=2025-06-04T00:00:00Z). If you use the same date for both, you may get an empty result. Reference

6. Why your slots may be off: If you pass local time as UTC (or vice versa), or if your start/end times are not properly converted to UTC, the slots returned will not match what you expect. Always convert from the user's intended local time in their timezone to UTC before making the API call.

Summary:

• Always convert local date/time + timezone to UTC ISO string before calling the API.
• Ask your AI model for YYYY-MM-DDTHH:mm:ss format.
• Use the v2 slots API for more robust features.
• Double-check your slot search window logic (especially for single-day queries).

This approach will ensure your slot availability checks and bookings are accurate and timezone-safe.

To reply, just mention my name @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}