Hey guys,
Ran into an edge case where tasklib completely fails to parse a task if it contains an older historical creation date.
How it happens:
If you manually force an old date on a task using task edit (for example, setting Created: 1979-07-14 00:00:00), Taskwarrior 3.x saves it to the SQLite database just fine.
However, when a frontend library like vit tries to initialize and read the tasks via tasklib, it throws this validation error and gets stuck in an infinite loop:
Plaintext
'300769200' is not a valid date in the '' format.
It looks like the internal date parser chokes on the smaller Unix timestamp integer (300769200) coming out of the modern Taskwarrior 3 SQLite backend, treating it as malformed text.
Changing the date back to a modern timestamp via the standard CLI (task modify entry:2026-07-01) fixes the issue immediately, but it would be great if tasklib had a defensive check or fallback format handler here to stop the parser from completely dying on older dates.
Hey guys,
Ran into an edge case where tasklib completely fails to parse a task if it contains an older historical creation date.
How it happens:
If you manually force an old date on a task using task edit (for example, setting Created: 1979-07-14 00:00:00), Taskwarrior 3.x saves it to the SQLite database just fine.
However, when a frontend library like vit tries to initialize and read the tasks via tasklib, it throws this validation error and gets stuck in an infinite loop:
Plaintext
'300769200' is not a valid date in the '' format.
It looks like the internal date parser chokes on the smaller Unix timestamp integer (300769200) coming out of the modern Taskwarrior 3 SQLite backend, treating it as malformed text.
Changing the date back to a modern timestamp via the standard CLI (task modify entry:2026-07-01) fixes the issue immediately, but it would be great if tasklib had a defensive check or fallback format handler here to stop the parser from completely dying on older dates.