Hello,
I have been trying to include timezone for meeting start time and for some reason I have been getting inaccurate start time being supplied to new Zoom meetings.
A meeting created with above details records a new zoom meeting with following details
I am not sure about how to fix it. I would appreciate a lot if anyone could help me.
Thank you
Wbat value is being passed as start_time when you create the meeting? We standardized on UTC for exchanging timestamps and then convert to the local time zone when it displayed, so a typical value looks like 2021-03-26T12:30:00Z.
You can get some samples of requests your application is making from the API Call Logs.
Hello Chris,
Thank you for the response. I check the logs and here’s the portion of the request body being sent for the above meeting.
{“start_time”:“2022-06-17T16:30:00Z”,“duration”:60,“timezone”:“Asia/Kathmandu”}
My assumption is that Zoom API will process the start time with the provided timezone and the meeting would be created with start time for 4:30 PM Kathmandu.
However, the result I got was 10:15 Kathmandu (as in the screenshot above)
So, am I missing something important or basic here ?
Please let me know.
Thanks and Regards
Sorry, I forget to mention you in the previous reply. Hope this one rings a notification on your account.
The start time has a UTC time zone (due to the Z suffix), so Zoom is going to treat that time as if it was 16:30 UTC, then for display purposes, add 5:45 for Kathmandu. If you actually want to indicate 16:30 in Kathmandu’s time zone, try specifying that time zone offset, for example, 2022-06-17T16:30:00+05:45. These timestamps are formatted according to ISO 8601, to help with looking up reference information.
That said, Zoom is an international product and date and time handling is messy, so it’d be easier for both sides if you exchange times in UTC and then convert to local time when displayed.
Okay, by this do you mean that the current behavior is the way to go ?
And I should be converting the 10:15 to local time for displaying to users?
Are we on the same page here ? @MultiplayerSession
Standard development practice is to store timestamps internally in the UTC time zone and then convert it to local time when it’s shown to users. In this example, you would store the timestamp as 2022-06-17T10:45:00Z internally in your application and pass that to Zoom, but when you display this time to users, adjust it based on their time zone.
Alright, I have applied the changes to my zoom data preparation logic and now the issue appears to be resolved. To be clear, I converted the local date time to UTC date time string and supplied that to Zoom API.
One last question though, @MultiplayerSession , is this conversion necessary for meeting updates via API as well ? Currently, I am supplying unprocessed local date time string with an added ‘Z’ at the end and the update seems to be accurate.
It’s hard to definitively say; the assumption I’d follow is to always express times in UTC when exchanging information with other systems, since local time zones are a nightmare to keep accurate at a global scale. For practical purposes, this means that UTC timestamps are well-tested and will work, while support for local timestamps will probably get skipped or overlooked, so I’d prefer to avoid any potential problems entirely.
In our application, when we call the “Update a meeting / webinar” APIs (PATCH /meetings/{meetingId} etc.), we’re always storing timestamps in UTC internally, and exchanging them with Zoom that way.
