Accept ISO8601 dates with milliseconds?

API and Webhooks
1

I was debugging why start_time timestamps were incorrectly echoed by the Create Meeting API call:

{
  topic: "Test start time 2020-04-15T19:55:00.000Z",
  type: 2,
  start_time: "2020-04-15T19:55:00.000Z",
}

Response:

{
  topic: "Test start time 2020-04-15T19:55:00.000Z",
  type: 2,
  status: "waiting",
  start_time: "2020-04-16T02:55:00Z",
  timezone: "America/Los_Angeles",
}

Note the all times were in the Zulu timezone, but the start_time in the response came back off by 7 hours, the America/Los_Angeles offset.

Turned out this surprising error was caused by including the milliseconds in the start_time request. I know the format is documented to not have milliseconds, but I was using .toISOString() in JavaScript, which I suspect is a common error others may make.

If I send the start_time without the .000 part, the response correctly returns the same start_time value.

I’ve since added code to strip the milliseconds from the start_time before sending the request, but it would be nice if the API were more robust and accepted RFC3339 timestamps with milliseconds.

Thanks! :slight_smile:

2

Hey @Civility,

Nice find, we will consider fixing this, however, our docs due state to set the start_time as:

YYYY-MM-DDTHH:MM:SSZ.

Thanks,
Tommy