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 }
