PUT /projects/{projectId}/tasks/{taskId}/date must have start.time include seconds
planned
yolk
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
:Pfrom 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
}
Log In
John at Taskade
Great catch — and thanks for documenting the inconsistency so precisely. You are absolutely right that start.time requiring seconds (e.g. 16:12:00) while end.time does not is an undocumented quirk that can bite API consumers unexpectedly.
Inconsistencies like this between start and end field parsing are the kind of thing that should be normalized at the API layer, not worked around in client code. We have flagged this for our API maintenance queue.
The practical workaround for now is to always include seconds in both start.time and end.time to ensure consistent behavior regardless of which field you are setting. It is slightly more verbose but avoids any parsing edge cases.
We appreciate you digging into this level of detail — API consistency reports like this help us catch issues that automated tests often miss. We will aim to address this and update the docs accordingly. Keep the reports coming!
John at Taskade
Update: This is on our roadmap!
We've prioritized this based on your votes and feedback.We're planning to include this in an upcoming release. Stay tuned for updates!
In the meantime, check out what's new:
- **Taskade Genesis** — generate AI-powered apps, agents, and workflows instantly
- **Community Hub** — 1000+ free templates and apps to explore
Follow our progress: Changelog | Product Updates
Thanks for voting and helping shape Taskade!
John at Taskade
marked this post as
planned
Thanks for the API feedback!
Improving date precision in the API is on our roadmap.Explore what's available now:
- Build with Taskade Genesis — create AI apps, agents, and workflows instantly
- Browse Community Hub — clone templates and AI agents for free
Stay updated: Changelog | Product Updates