Unable to retrieve incremental updates for table (users)

[pgo586]

Not sure whether this is supposed to be enabled for us yet or not, but I tried earlier today to retrieve an update for the users table using the provided bash script, and the process did not work because the Job_id was being set as null. This is what the output looked like:

  $  ./update.sh users 2022-06-24T10-37-00-05:00 update_users_06-29-22-10-55-am.json
- Connecting to https://dap.insk8s.net
- Table 'users', query '{"format":"jsonl","since":"2022-06-24T10-37-00-05:00"}', Canvas account 18760000000000195
- Authenticate in DAP
- Initiating update request
- Waiting for job null to complete
- Received job state 'null' for job ID 'null'
- Received job state 'null' for job ID 'null'
- Received job state 'null' for job ID 'null'
- Received job state 'null' for job ID 'null'
- Received job state 'null' for job ID 'null'
- Received job state 'null' for job ID 'null'
- Received job state 'null' for job ID 'null'
- Received job state 'null' for job ID 'null'
- Received job state 'null' for job ID 'null'
- Received job state 'null' for job ID 'null'

[reynlds]

When I've gotten "null" returns it was due to malformed requests (typos or non-existent tables) or an expired token (1 hour be default I believe). Is the time string correctly formatted?

[chriscas]

@pgo586,

I'm pretty sure the time units in ISO format need to be separated by colons instead of dashes...  So instead of sending 2022-06-24T10-37-00-05:00, try 2022-06-24T10:37:00-05:00.

-Chris

[pgo586 · Accepted solution]

Thanks @chriscas for your response. However, when I correct for this, and then tried a couple different ways of representing the time zone (such as -05:00, -5:00) . none of them worked. So you definitely have a point about the formatting for the timestamp part (I hadn't realized I was using dashes instead of colons), but I also see that the API seems to be unable to understand an arbitrary time zone and is only accepting the universal timezone (Z). In re-reading the API reference, I see that indeed, the API *only* accepts the universal time zone in these timestamps, and so my inputs were definitely not as expected in more than one way.