03-02-2018 04:50 AM
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.
Solved! Go to Solution.
03-05-2018 11:54 AM
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.
03-02-2018 01:50 PM
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.
03-05-2018 06:37 AM
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
03-05-2018 11:54 AM
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.
03-06-2018 12:10 AM
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).
03-06-2018 12:55 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide