Figure I'd mention another quirk, although in practice it wouldn't matter that much
While
PUT /projects/{projectId}/tasks/{taskId}/date
accepts a JSON body with two keys of
start
and
stop
, they're read differently.
You must include seconds in a
start.time
, like
16:12:00
, while an
end.time
doesn't care, and both
18:12
and
18:12:00
will be parsed correctly, and be the same time.
Another quirk is that the GitBook docs don't explain what format each field is expecting (1st screenshot) https://developers.taskade.com/docs/api/tasks/date
While the OpenAPI playground page shows the expected format, however it's got a few problems (2nd screenshot) and body snippet copied below https://www.taskade.com/api/documentation/static/index.html#/Task/taskPutDate
The first part of the quirk of the OpenAPI example body sometimes shows seconds on the
end.time
key, but it only fails if it's not included on the
start.time
key. The other is that these dates are wayyyy off into the future. Other times it will show seconds on
start.time
, the values are faked, or mocked which makes sense.
It's a superficial issue, but I figured I include it since I wasn't sure if I was supposed to use some other calendar at first, when I started to get errors for not including seconds in
start.time
:P
from the OpenAPI Playground Example Body - different than the screenshot, and sometimes it will render a
start.time
with seconds, it's random:
{
"start": {
"date": "8692-82-26",
"time": "23:44",
"timezone": "string"
},
"end": {
"date": "5809-32-83",
"time": "21:56:45",
"timezone": "string"
}
}
The error when not including
:SS
on
start.time
is the 3rd screenshot and is like:
HTTP 500
{
"ok": false
}