Wrong start_time value for a recurring meeting

[ezyezyck (Ezhi)]

Description
Hi there!
I’m trying to get this week’s upcoming recurring meetings before creating a new one to prevent concurrent meetings.
As a result, I have a list of meetings with start_time values.
But this value is the last iteration’s start time for a recurring meeting.
Is this the right value?
Is there any way to get start_time of the first(or current) recur of a recurring weekly meeting?

Error
Strange start_time value for a Recurring meeting

Which App Type (OAuth / Chatbot / JWT / Webhook)?
JWT

Which Endpoint/s?
GET /users/{userId}/meetings

[tommy (Tommy Gaessler)]

Hey @ezyezyck,

Can you share the response body JSON so I can debug?

Thanks,
Tommy

[wagedu (Nathan)]

I’m having the exact same problem.
The list of Meetings is followed by the ENDING date of the recurring event.
Also using JWT app -> Fooevents for Woocommerce.
No idea where I’d find the response body JSON for it.

[tommy (Tommy Gaessler)]

Hey @wagedu,

Please share steps to reproduce the issue and your request body JSON so I can help.

Thanks,
Tommy

[wagedu (Nathan)]

Hi @tommy,

I know it’s apparently a purely “cosmetic” issue but my client uses the same name for a 7 weeks course they are repeatedly teaching every 2 months. As you can see, having the worng “start date” at the end of the same name, will surely lead to lots of problems.

I’m using the Wordpress plugin Fooevents and apparently this issue was already notified to you/Zoom.
They just sent me the info they already sent to your team, so I’ll paste it here, with their comments in italics. Thanks in advance!
OOPS… “New users can put only 2 links in a post”… So, I’ll have to change part of the code to avoid it having the link format. I’ll mark it as “zxzx” ok?
//

You can send them the same as what we sent for the list of meetings that contains a recurring meeting:

{
“page_count”: 1,
“page_number”: 1,
“page_size”: 300,
“total_records”: 1,
“meetings”: [
…
{
“uuid”: “",
“id”: 123456789,
“host_id”: "",
“topic”: “Fitness Class”,
“type”: 8,
“start_time”: “2022-04-12T11:00:00Z”,
“duration”: 60,
“timezone”: “Africa/Johannesburg”,
“agenda”: “Example of an 8 week bi-weekly fitness class”,
“created_at”: “2020-04-09T10:08:13Z”,
“join_url”: "httpzxzx://us02web.zoom.us/j/?pwd=*************************”
}
…
]
}

To see why the start time is incorrect, when fetching this individual meeting to view its occurrences, the response is:

{
“status”: “success”,
“data”: {
“uuid”: “",
“id”: 123456789,
“host_id”: "",
“topic”: “Fitness Class”,
“type”: 8,
“status”: “waiting”,
“timezone”: “Africa/Johannesburg”,
“agenda”: “Example of an 8 week bi-weekly fitness class”,
“created_at”: “2020-04-09T10:08:13Z”,
“start_url”: "httpzxzx://us02web.zoom.us/s/",
“join_url”: "httpzxzx://us02web.zoom.us/j/?pwd=",
“registration_url”: “httpzxzx://us02web.zoom.us/meeting/register/****************",
“password”: "",
“h323_password”: "",
“pstn_password”: "”,
“encrypted_password”: "**”,
“occurrences”: [
{
“occurrence_id”: “",
“start_time”: “2022-03-01T11:00:00Z”,
“duration”: 60,
“status”: “available”
},
{
“occurrence_id”: "”,
“start_time”: “2022-03-04T11:00:00Z”,
“duration”: 60,
“status”: “available”
},
…
{
“occurrence_id”: “",
“start_time”: “2022-04-08T11:00:00Z”,
“duration”: 60,
“status”: “available”
},
{
“occurrence_id”: "”,
“start_time”: “2022-04-12T11:00:00Z”,
“duration”: 60,
“status”: “available”
}
],
…
}
}

–

[tommy (Tommy Gaessler)]

Hey @wagedu,

Unfortunately Fooevents has integrated with Zoom improperly. They need to utilize our OAuth flow and if there is a bug, they need to reach out to us directly so we can help.

Thanks,
Tommy

[fooevents]

Hi Tommy

Just to clarify for future readers of this post, the original poster isn’t a customer of FooEvents so the issue is not related to how FooEvents integrates with Zoom’s API. I’m not sure how you can identify an incorrect implementation based on a partial JSON string which was returned directly from an API request, but as per the Zoom API documentation our implementation requires JWT tokens for server-to-server authentication and requests.

We will continue to communicate directly with you regarding our implementation, but for other readers’ benefit, the start time when fetching a list of meetings/webinars seems to be the start time of the last occurrence of a recurring meeting/webinar as is seen when fetching the individual meeting/webinar and inspecting the individual occurrences.

[tommy (Tommy Gaessler)]

Hey @fooevents,

We will reach out to you about your app authentication method. CC @abe.queen @TimZoom.

As for the wrong start_time value, I will need to see the full request body JSON and response JSON. Feel free to send it to developersupport@zoom.us so we can debug it.

Thanks,
Tommy

[developer-whova (Developer)]

Hi @tommy,

It seems that the recurring meeting does have a bug in the update API of meeting and webinar. It occurs only when updating the timezone of a recurring meeting. After the update, the timezone is updated correctly, but the start time is not correct. Below are the steps to reproduce.

1. Create a recurring meeting/webinar, here is an example with start time to be 09/30/2020, 11pm central time.

   

2. Send an update request that changes only the timezone of the meeting. The timezone must be different from the original timezone in order to reproduce. For this example, we change the timezone from central time to pacific time in this request with the start time unchanged (want it to be 11pm still), that is, 09/30/2020 11pm in pacific time. Converting this datetime to UTC is ‘2020-10-01T06:00:00Z’. Below is the update request body
   {
   “agenda”: “sad”,
   “duration”: 60,
   “password”: “”,
   “recurrence”: {
   “end_times”: 7,
   “repeat_interval”: 1,
   “type”: 1
   },
   “settings”: {
   “alternative_hosts”: “”,
   “audio”: “both”,
   “auto_recording”: “none”,
   “host_video”: false,
   “join_before_host”: true,
   “mute_upon_entry”: false,
   “participant_video”: false,
   “waiting_room”: false
   },
   "start_time": “2020-10-01T06:00:00Z”,
   "timezone": “America/Los_Angeles”,
   “topic”: “sdasd”,
   “type”: 8
   }

3. After the update, go to zoom meeting detail page and check the start time of the meeting. For this example, the timezone is updated correctly, but the start time is not updated correctly. Now the start time of this meeting becomes 09/30/2020, 9pm instead of staying at 11pm on Zoom.
   

   

This is reproducible only with recurring meeting. If I try the same process with a non-recurring meeting, the start time shows up correctly.
Can you please check if you can reproduce this issue? Thanks!

[tommy (Tommy Gaessler)]

Hey @developer-whova,

Thanks for sharing this. We are aware of this bug, and looking into the issue (ZOOM-191043):

Changing Timezone through Update meeting API is not working properly - Recurring meeting

Description I created a recurring meeting today at 8 AM Kolkata time and then updated it to 8 AM Vancouver Time… Create meeting successfully created the meeting at 8 AM Kolkata which is correct, when I give the update to change the meeting to 8 AM Vancouver, It does not do that and changes the time of meeting according to timezone selected first. This is the case with any timezone change, It does not change that properly… Please see my attached data below. Request 1 to set timezone to Asia/Ko…

Thanks,
Tommy

[tommy (Tommy Gaessler)]

Hey @developer-whova, @fooevents, @wagedu, @ezyezyck,

This is currently slated to be fixed in November.

Thanks,
Tommy

[diffdennis (Dennis)]

Hey @tommy, I also have this problem (with non-recurring scheduled meetings).
If I set the start_time to a time in the future, the Create Meeting API endpoint anyway returns the current time (same as created_at) in the start_time field.

Is this the same error that will be fixed in November?

Thank you!

[diffdennis (Dennis)]

To add some info, this is my request body JSON:

{"type":2,"duration":15,"start_time":"2020-11-13T10:54:51.735Z","topic":"...","agenda":"...","password":"..."}

And this is the response:

I set the start_time to 30 minutes in the future and I’m using GMT date strings only.

[diffdennis (Dennis)]

@tommy Now I see the problem here - the JavaScript toISOString() returns milliseconds, which the API doesn’t expect. That was the problem, sorry for bothering you!

[will.zoom (Will)]

Hey @diffdennis, glad to hear you figured it out!

[fu.wire (Oscar)]

I just wanted to leave here my appreciation for this post, it saved me hours of debugging

[shishir.gaire11 (Shishir)]

Hey there, I have created meetings using zoom’s meeting api, and when I create the meeting of type 2, the start and end times are set correctly but while I create meeting type 8, the start and end times are way out of the original ones…

this is the data for type 2:
{“topic”:“sadasdasd”,“start_time”:“2024-2-15T05:16:00+05:45”,“duration”:“123”,“type”:2,“default_password”:true,“settings”:{“mute_upon_entry”:true,“participant_video”:false,“auto_recording”:“local”}},

this is the data for type 8:
{“topic”:“testing”,“start_time”:“2024-2-15T06:00:00+05:45”,“duration”:“120”,“type”:8,“recurrence”:{“end_date_time”:“2024-2-22T08:00:00+05:45”,“type”:1,“repeat_interval”:1},“default_password”:true,“settings”:{“mute_upon_entry”:true,“participant_video”:false,“auto_recording”:“local”}}

any help will be appriciated.

and this was working till this morning; for your information.