When an attendee joins a webinar and they are waiting for the host to start the meeting, there is a message with the meeting start date.
On the WebSDK it shows the time with GMT 0 which is pretty confusing. On the other hand, the Zoom web browser app, shows the meeting time in local time.
Can the local time be added to the WebSDK? or I’m missing some configuration?
Thank you for posting in the Developer Forum. It looks like this question has already been asked and answered. Please see this developer forum post and let me know if you have any questions or clarifications:
I don’t think that topic is related at all to the issue I posted.
So yeah, when creating a webinar/meeting using the API we send the date and timezone that’s fine and works, that’s why in the Zoom app and the Zoom Web Browser the date-time is displayed correctly(See images above)
When using the Zoom Meeting SDK it doesn’t matter what you do it will show the date-time with GMT 0, so it seems to me it’s an issue parsing the date-time on the library.
Is there a solution? I have exactly the same problem. I have implemented Zoom Meeting into our virtual events web app using the Web SDK. Everything works fine (creation signature, connecting to meetings, etc). The problem is that when someone tries to enter the meeting before it starts, the meeting start time is displayed in GMT 0, which is an hour earlier than the time set when scheduling the meeting with Zoom. When starting the meeting with the Zoom client software, the correct time is displayed . I desperately needed a solution to this problem. I have an online event next week with more than 1000 visitors online and many different Zoom meetings. With this error the SDK is not usable for this.
@giancarlo1 , @VinodGodti
I use zoom-meeting-2.2.0.min.js. I have seen that there the meeting date is converted to a UTC string for the message output (“Meeting has not started”).
o=e.meetingDate and then o.toUTCString()
This will display the time in GMT 0. So for me in Germany one hour too early. No idea why this is so. Since no one from ZOOM seems to understand the problem and wants to help, I will change this in the .js file for testing. It’s of course only a quick workaround for me. Please let me know if someone has a better solution for this.
@giancarlo1, @olaf.becker, @VinodGodti,
Your patience is appreciated – any delays are certainly unintentional. Regarding your messages, I’ve reached out internally to have this behavior looked at closer [ZSEE-44755]. Please be assured this topic is being prioritized and another update will follow as soon as possible.