API: timezone returned that's not in docs

API and Webhooks
1

Description
Hi. I’m seeing the API return invalid timezones. For example, meeting with ID 91485083549 returns “Mountain Standard Time” but that’s not one of the valid timezones you list in the documentation.

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

Which Endpoint/s?
/v2/users/me/meetings and /v2/meetings/MEETINGID amongst others (see below for example)

How To Reproduce (If applicable)
Steps to reproduce the behavior:

  1. Retrieve /v2/meetings/91485083549
  2. See timezone field is “Mountain Standard Time” and compare to documentation where this is not listed as a valid timezone

It’s particularly strange because some other events by the same user appear as America/Denver or America/Edmonton which is expected behavior and in line with the documentation.

2

Hi @xeio,

Thanks for reaching out about this.

Can you share the API response body where you’re seeing this returned? This will help me to take a closer look.

Best,
Will

3

Hi @will.zoom - sure thing, here is the response to /v2/meetings/91485083549 - I’ve removed the user’s data:

{
    "uuid": "Mz/CX3zNQkKdgcso7nQnSw==",
    "id": 91485083549,
    "host_id": "--REMOVED--",
    "host_email": "--REMOVED--",
    "assistant_id": "",
    "topic": "--REMOVED--",
    "type": 2,
    "status": "waiting",
    "start_time": "2021-02-18T00:30:00Z",
    "duration": 120,
    "timezone": "Mountain Standard Time",
    "agenda": "",
    "created_at": "2020-09-14T15:18:54Z",
    "start_url": "--REMOVED--",
    "join_url": "--REMOVED--",
    "password": "--REMOVED--",
    "h323_password": "--REMOVED--",
    "pstn_password": "--REMOVED--",
    "encrypted_password": "--REMOVED--",
    "settings": {
        "host_video": false,
        "participant_video": false,
        "cn_meeting": false,
        "in_meeting": false,
        "join_before_host": false,
        "jbh_time": 0,
        "mute_upon_entry": false,
        "watermark": false,
        "use_pmi": false,
        "approval_type": 2,
        "audio": "both",
        "auto_recording": "none",
        "enforce_login": false,
        "enforce_login_domains": "",
        "alternative_hosts": "",
        "close_registration": false,
        "show_share_button": false,
        "allow_multiple_devices": false,
        "registrants_confirmation_email": true,
        "waiting_room": true,
        "request_permission_to_unmute_participants": false,
        "global_dial_in_countries": [
            "US"
        ],
        "global_dial_in_numbers": [--REMOVED--],
        "registrants_email_notification": true,
        "meeting_authentication": false,
        "encryption_type": "enhanced_encryption",
        "approved_or_denied_countries_or_regions": {
            "enable": false
        },
        "breakout_room": {
            "enable": false
        }
    }
}
4

Hi @xeio,

Thank you for sharing this. When you created the meeting did you pass the start_time in local time or GMT? (including a Z at the end of the timestamp vs. not including it)

Let me know when you have a chance—thanks!
Will

5

Hi @will.zoom - perhaps some crossed wires here, I did not create the meeting; it was retrieved from your API with a GET request to /v2/meetings/91485083549 using a customer’s OAuth credentials and is their meeting. The timestamp isn’t the issue - the timezone field is the issue; the value the API has returned (Mountain Standard Time) is not one that your docs list as valid, which caused an exception in my code.

Note I’ve now manually altered all of the events on this user’s account and set the timezones to America/Edmonton just so the client can use our app - but it would be great to have this fixed for the future.

6

Hi @xeio,

I see—thank you for clarifying. I now see what you’re referring to.

I’m looking into this for you (ZOOM-247903).

I’ll follow up with you here shortly,
Will

1 Like
7

Hi @xeio,

After checking with our Engineering team, we haven’t so far been able to reproduce this—is it possible to provide the exact timestamp of one of the requests that has returned “Mountain Standard Time” in the response? Additionally, is there anything on your end that could be manipulating the API response, or is this the raw response you’re receiving back directly from Zoom servers?

Let me know when you have a chance, thanks!
Will

8

Hi @will.zoom, thanks for following up.

Sure thing - here are some timestamps of calls to https://api.zoom.us/v2/users/me/meetings on behalf of user oZL0EZXYTNGeRQ2D_8dzFg which returned Mountain Standard Time in several meetings’ timezone fields:

2021-02-11 22:28:58.118 GMT
2021-02-11 22:29:04.703 GMT
2021-02-17 18:28:14.524 GMT
2021-02-17 18:28:19.018 GMT
2021-02-17 18:29:16.788 GMT
2021-02-17 18:31:59.599 GMT
2021-02-17 18:32:33.502 GMT

In terms of your question, no that was the raw API response received - and I double checked via Postman; the example above it was directly pasted from Postman with no changes (except to obscure the client’s data.)

Thanks.

9

Hey @xeio,

Thanks for providing these additional details. We are looking into it further.

-Will

1 Like
10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.