Adding support for date-time information using ISO8601

[apfelchips]

ISO8601 notation should be usable in all current date-only fields:
completion + creation date, and due date.

Currently the Todo.txt Spec only allows for calendar date precision, but most tasks are usually shorter than a whole day and can also have time sensitive deadlines.

example usage:

add ISO8601 support due:2018 <--  interpreted as 2018-01-01T00:00
add ISO8601 support due:2018-08 <-- interpreted as 2018-08-01T00:00
add ISO8601 support due:2018-08-25T17:15
add ISO8601 support due:2018-08-25T17:15:54.2980
add ISO8601 support due:2018-08-25T17:15Z <-- interpreted as 2018-08-25T17:15+00:00
add ISO8601 support due:2018-08-25T17:15+02
add ISO8601 support due:2018-08-25T17:15:54+02:00
add ISO8601 support due:2018-08-25T17:15:54.2980+02:00

• Every date-time without a specified Timezone will be considered to be in the local system time zone.
• Milliseconds can be arbitrarily precise.
• Imprecise values will be floored to the earliest moment in time.
• Applications should default to the 2018-08-25T17:15 format when automatically inserting entries.

Optional

Fault Tolerance

Add some resilience in the spec to compensate for human errors. For example the following isn't compliant (not even in the current todo.txt spec), but still unique.

add ISO8601 support due:2018-8-2
add ISO8601 support due:2018-08-25T17:15+2
add ISO8601 support due:2018-8-02T12:5
add ISO8601 support due:2018-8-02T12:05-0

Human readable Time zone codes instead of just offsets

Though there is some dispute about those codes, it would help with usage.
I suggest specifying the offical IANA abbreviations as canon (abbreviations would have to be extracted manually, or via a custom script).

examples:

2018-07-25T17:15UTC => 2018-08-25T17:15+00:00
2018-07-25T17:15CET => 2018-08-25T17:15+01:00
2018-07-25T17:15CEST => 2018-08-25T17:15+02:00

[Lost-Projects]

I agree with this proposal. I recently requested that a Thunderbird extension support time as part of the due date.
rkokkelk/todo.txt-ext#45
The developer responded that the format did not support time. This somewhat surprised me as I know it is possible the extend the specification in the key:value format. I had rashly assumed that someone had added time support. Perhaps someone has? But of course, anyone implementing this for their own use might find that their chosen time format does not match that of anyone else who may implement this function. As the todotxt format was designed to be platform and even application agnostic, this can create a kind of 'forking' where different applications are implementing different extensions to the format that won't work with each other.
I recognise the proposed time format from ical / ics calendar files and this is what I would choose.

It is stated that this is the ISO8601 format. I've read other proposals here about standards and encoding and to broaden the proposal, I suggest that Ms Trapani or whoever is in charge of the format decide on some principles such as encoding and existing format standards. She/they can then approve (or not) proposals for extensions to the format.
So, people can extend however they want for their own use, but they can propose extensions to the main project here. If those extensions conform to chosen standard, they are approved. This way, everyone who wishes to enable that extension in their own app can do it using the same format, preserving interoperability. If no standard has been chosen, the owners of this project can chose one. If no standard exists, the owners can accept the format proposed or define their own.

[tomByrer]

I love this format! I make it my default when I can in my OS (eg Windows).
(It was torture being an American who lived in a few EU states....)

[voxelias]

Is there a real reason to support more than UTC (with Z ending) and local (without Z) formats?

[apfelchips]

@Lowentwickler This would be useful for deadlines from different places/teams around the world, also why not it is already in the ISO standard :)

[voxelias]

@apfelchips Of course, if you co-work with people around the world, why not to keep all dates and times in UTC in file, so client software can convert it to your local time zone. I don't see a reason to have in a file those +08:00 and -02:30. Also I can hardly pretend anybody writing this by hand...
I think simplicity is one of the biggest advantages of todo.txt. I have nothing against ISO timestamps for creation and completion as a feature, but speaking about due: tag - it is optional. It could contain even due:lunch. And it is a 100% on a user side what to put there and on a software side, how to handle this. Why this should be in a format at all?

[davidstosik]

I like the idea, and think it would be useful, but am afraid it would break all existing clients that would be unable to parse dates until they've been upgraded.

If this happens, I'd suggest to start versioning the specification (and maybe the todo.txt file itself).

[tensau]

Missing support of time informations is the only thing that keeps me from migrating from a caldav-based solution to todo.txt...

[a-e-e-m]

Is there any progress on specifying due dates and time in todo.txt and compatibility with Thunderbird? I would be very interested in this. Also, a starting time (not the creating time, I think), would be useful.

[Moonbase59]

I’d also strongly support the notion for ISO-8601 dates. Of course things like "due:" are already an extension to the core, and todo.txt more targeted towards coarse planning, BUT it’s sometimes nice to add a "start due time", like for instance, my physicians open at different times, so I’d use something like due:2021-02-26T08:30. Or due:2021-02-26T17:00Z for the start of an international video conference.

My todo.txt is synced between my desktop, my laptop, and my Android smartphone using Syncthing. On Android I use Markor, and Todour on my Linux machines.

[AaronKnowls]

I'm also looking forward to using time along date.

Is there any news on this?