cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1804
Views
0
Helpful
5
Replies

Meeting usage- and attendee history returns wrong time?

john.cleese
Level 1
Level 1

Hello,

I am using WebEx XML API V10.0.0 SP23.

I am on Central European time (Paris/Brussels/Amsterdam...).

When calling LstmeetingusageHistory and LstmeetingattendeeHistory API methods, the returned time fields (history:meetingStartTime, meeting/EndTime, joinTime, leaveTime) are 1 hour too early.

For instance, I had a meeting which started on 12:12 and ended on 12:30. But LstmeetingusageHistory returns the following:

<history:meetingUsageHistory>

    ...

    <history:meetingStartTime>03/01/2018 11:12:34</history:meetingStartTime>

    <history:meetingEndTime>03/01/2018 11:30:41</history:meetingEndTime>

    ...

    <history:timezone>GMT+01:00, Europe (Paris)</history:timezone>

    <history:timeZoneID>23</history:timeZoneID>

    <history:timeZoneWithDST>Paris (Europe Time, GMT+01:00)</history:timeZoneWithDST>

What is surprising is that GetMeeting API method returns the scheduled meeting start time correctly!

<meet:schedule>

    <meet:startDate>03/01/2018 12:10:00</meet:startDate>

    <meet:timeZoneID>23</meet:timeZoneID>

    <meet:timeZone>GMT+01:00, Europe (Paris)</meet:timeZone>

    ...

So, why are these inconsistent?

Does it mean that time fields returned by LstmeetingusageHistory and LstmeetingattendeeHistory are in GMT+0 and I have to manually apply the "+01:00" for my local timezone?

And what about the daylight saving time? Does it mean that after 25 March 2018, I will have to correct time fields returned by these two methods by +2 hours?

Thanks.

1 Accepted Solution

Accepted Solutions

I was able to figure out what was happening after my own test meeting report was ready. It seems that GMT/UTC time is being returned when no specific time zone is requested, even if the returned TimeZone, TimeZoneWithDST, and TimeZoneID all differ. Specifying timeZoneID in your request will result in the correct time being returned;

<timeZoneID>23</timeZoneID>

It seems the bug is that timeZone, timeZoneWithDST, and TimeZoneID in the response are incorrect and are not affected even by setting timeZoneID in the request. This bug will be reported for correction in a future release.

View solution in original post

5 Replies 5

nmorrow
Cisco Employee
Cisco Employee

Hello,

     The time listed in GetMeeting is the time the meeting was scheduled to start, this is not strictly enforced. The time reported in LstmeetingusageHistory is the time that the meeting was actually opened and may differ significantly from the scheduled start time at the host's discretion. I have scheduled and held a meeting in Paris time to test output of LstmeetingusageHistory to a known time, but it will take some additional time for final report to be generated so I can verify correct time. You may also compare your LstmeetingusageHistory output to manually pulled reports from the same WebEx site to verify that times match.

Hello,

I understand that any meeting might not start exactly when it was scheduled, but the problem happens when I run this scenario all by myself:

1. I schedule a meeting starting in 15 minutes from now.

2. I join it.

3. I leave.

4. I wait until usage statistics become available.

5. I call LstmeetingusageHistory and LstmeetingattendeeHistory and they both return start/end join/leave times one hour too early.

Also, please note that:

- it does not matter whether I create the meeting via API CreateMeeting or through WebEx web page

- GetMeeting returns the correct startDate and timeZoneID = 23

- LstmeetingusageHisotry and LstmeetingattendeeHistory also return timeZoneID = 23, but incorrect time

I was able to figure out what was happening after my own test meeting report was ready. It seems that GMT/UTC time is being returned when no specific time zone is requested, even if the returned TimeZone, TimeZoneWithDST, and TimeZoneID all differ. Specifying timeZoneID in your request will result in the correct time being returned;

<timeZoneID>23</timeZoneID>

It seems the bug is that timeZone, timeZoneWithDST, and TimeZoneID in the response are incorrect and are not affected even by setting timeZoneID in the request. This bug will be reported for correction in a future release.

Hello,

It seems that indeed, adding the <timeZoneID> parameter to the request fixes the problem for LstmeetingusageHistory!

However, the parameter does not exist in LstmeetingattendeeHistory, and adding it to the request causes the following error:

validation: unable to find FieldDescriptor for 'timeZoneID' in ClassDescriptor of lstmeetingattendeeHistory

So, I will assume that join/leave dates/times returned by LstmeetingattendeeHistory are UTC+0 and living in Europe, I need to add 1 hour (and 2 hours in the summer).

Hello,

     I hadn't noticed that time zone was not returned with attendee history before, but that is unfortunately correct. In the attendee history case, you can reliably assume GMT/UTC and make the offset correction in code. You can make the same assumption with usage history when not providing a timeZoneID, but the response timeZone, timeZoneWithDST, and timeZoneID will all report an incorrect value until the previously submitted bug report is addressed. I imagine if the time zone elements correctly stated GMT/UTC that the originally reported times would have made sense.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: