Timestamps and Durations

[djmitche]

Taskwarrior's timestamps and durations are so complex that they require three (1 2 3) pages for their documentation.

Should we try to re-implement that? I expect doing so would involve a lot of typing and a lot of tests. It would also probably uncover some bugs in Taskwarrior where we'd have to decide whether to duplicate or fix the bug. And, there's the minor issue of Taskwarrior allowing a deprecated rc.dateformat config which I'm pretty sure we wouldn't want to reproduce.

If TC doesn't reproduce those formats exactly, what should it do?

This relates to #83 since waiting involves a timestamp.

[djmitche]

[UPDATE] I added duration parsing in https://github.com/taskchampion/taskchampion/compare/issue83, so all that's left is timestamp parsing. It might not be that much work, to be honest. I may just decide that ascension has no business being a privileged identifier :)

[djmitche]

TW supports iso8601 timestamps which .. have a ridiculous array of formats. I've chosen to only support rfc3339, AKA JS's .toJSON() format. And, I've added support for YYYY-MM-DD, setting that to the local midnight on that date.

[dbr]

So I suppose there is a few "date" things:

1. Moment in time (like when a task was created)
2. Repeat interval (e.g "every 2 days", "every second monday")
3. Relative time duration ("2 days ago")

For 1, iso8601 seems fine for now - I imagine we might want to allow these to be configuring into locale-dependent or configurable format in future (e.g 24/1/2000/1/24/2000/Jan 24st 2000`/etc etc etc)

For repeat intervals, I'd be inclined to reduce this to as small a set of options as practical. Currently the current list includes biweekly which is ambigious, lots of variations of the same (e.g about 9 variants on "month"), and some niche things (semiannual, seconds, a few holidays). Lots of things to support, lots of things to document, and lots of things for user to learn (plus less chance we can produce good clear error messages)

I almost wonder if we can get away with just supporting: every day, every week, every month, every year. Repeats on the same day as the start point of the repeat

I don't think we need seconds/minutes/hours, too granular. Most of the others can quite reasonably be done with every n days/weeks/months (e.g "every 2 weeks" instead of "fortnightly" seems fine)

Since it's not a calendar application, I'd be inclined to stop there personally.. However if we wanted to be fancy, the next step up would be to allow the tasks to repeat on specific days (e.g every second Monday), at which point I think the macOS Calendar "Repeat" option is a good reference:

• There is a simple "Every [day/week/month/year]" option. Just repeats on that day.
• "Custom" which then gives you a dropdown with "Frequency: [Daily/Weekly/Monthly/Annually]"
• "Daily" gives "Every [n] days"
• "Weekly" gives "Every [n] weeks on [M/Tu/W/Th/F/Sa/Su]"
• "Monthly" on "each [day of month]" or "on the [first/second/third/fourth/fifth] [day/week day/weekend day/Monday/Tuesday/etc]"
• ""Annually" gives "[n] years" "in [Jan/Feb/Mar/etc]" "on [the same options as monthly]"

Would need more thought, but i think this can be expressed with a concise CLI syntax, and also within GUI's (e.g web interface or an phone app), something like:

• ta repeat every 1 day
• ta repeat every 1 week on monday
• ta repeat every 2 month on first week day
• ta repeat every 5 year in june on second tuesday

(maybe makes sense to allow both year and years, and make the number optional, etc - although arguably the less options the better, we want to stay away from trying to do natural-language-parsing)

This also maps to a reasonable number of dropdowns for someone implementing a GUI widget

This would be a pretty rigid pattern, so we could give quite specific errors if user inputs something incorrect

However this does become somewhat of a rabbit-hole.. since the next step would be a way to stop repetition after n occurrences.. or after a specific date, or..

[djmitche]

Agreed regarding recurrence -- it probably makes sense to not try to reuse the duration keywords for that. I can remove the recurrence-specific words like biweekly from the PR. Recurrence is a separate issue (#81) so I'll leave these points until then.

Regarding localization - that's a good point, and something we can add when we add localization in general.

I actually don't think iso8601 is particularly convenient -- nobody wants to type "2000-01-24T13:30:00Z" in their command line. The more common option will be, I think, the date option.

I do want to keep the HMS aspect for two reasons: one, it defines an unambiguous moment in time, whereas a date could mean anything in a 48-hour-long span. If we define how a string giving only a date (like 2000-1-24) is translated into a specific moment (local midnight of that date), then it's unambiguous what might happen if replicas are running in different timezones.

The second reason is, at least for wait, waiting for a few hours is a useful thing. I do it all the time, for example when I have to wait for a bunch of CI tasks to run on a patch I'm working on -- task 123 wait:2h. Then the task is out-of-sight for the two hours, but reappears later in the day for me to check the CI results.

[dbr]

I actually don't think iso8601 is particularly convenient -- nobody wants to type "2000-01-24T13:30:00Z" in their command line. The more common option will be, I think, the date option.

Yep agreed!

The second reason is, at least for wait, waiting for a few hours is a useful thing. I do it all the time, for example when I have to wait for a bunch of CI tasks to run on a patch I'm working on -- task 123 wait:2h

It makes sense storing the wait-time internally with second-precision.

My doubt about the seconds/minutes/hours was more to do with the "repeat" function (e.g I can't think of many sensible reasons to repeat a task every x seconds!) - but with the "wait" use case it makes a lot of sense

[dbr]

Half-formed thought, would it make sense to allow repeating arbitrary commands, rather than tasks?!

Probably makes more sense in config rather than CLI (since ordering matters), but:

• ta repeat every 1 day: +auto done
• ta repeat every 1 day: add My todo! +auto

So every day, all tasks with the auto tag get marked as done, and a new one is added.

It seems like an interesting idea.. but possibly not a good idea

[djmitche]

So one of the tricky bits with recurrence is, it needs to work in a distributed environment. No one replica is "in charge" of applying a recurrence, so the plan is to have all replicas apply it and rely on the operational transforms to "merge" those applications. My thinking has been that the UUID is the only nondeterministic bit of a recurrence, so if we can design a way to generate the same UUID for an instance of a recurring task on every replica, then the operations will be identical everywhere.

Given that context, this kind of automation is pretty tricky. It would either need to be replicated and deterministic -- not possible in general, I think -- or occur on one replica with the results sync'd out using normal mechanisms. In the latter case, I'd rather it be implemented outside of the TC core, as some kind of integration. That could be as simple as a crontab for the example you gave, but more complex things could probably be a short Python script.