Specification of datetime ranges

[lauft]

Make specification of datetime ranges more flexible. Currently only datetimes in ISO format or simple times are allowed:

timew track 2018-12-12T09:00 - 2018-12-12T11:00 
timew track 20181212T0900 - 20181212T1100
timew track 09:00 - 11:00
timew track 9am - 11am

It should be possible to specifiy datetime ranges also as <date> <time> - <time>, e.g.

timew track 2018-12-12 09:00 - 11:00 
timew track 20181212 9am - 11am
timew track 9 - 11 2018-12-12
timew track monday 9 - 11
timew track :yesterday 9am - 11am

The remaining constraint would be that the given times are in the same format, e.g.

timew track 2018-12-12 09:00 - 11am
timew track 2018-12-12 0900 - 11:00

would be invalid.

[NotAFile]

I'd be very happy with this! Mixing not only date and time, but also say month and day would also be a great addition, if it is possible without major complications.

[grovesteyn]

Entering time intervals for a previous day is currently very cumbersome. Typing in long dates are prone to typos. The suggestion above by @lauft would make a huge difference.

[arooni]

also adding these as possible syntaxes that you may (or may not :P ) want to add support for:

9AM - 10aM // case insensitive times 9-10am // inferred time ranges to 9am-10am //dealing with spaces or lack there of in ranges 9-3 // implied 9am - 3pm 9 to 3 // allowing other delimiters

thanks for the great software!

[sruffell]

In addition to assuming yesterday as the date for times in the future #332, I would also like to be able to specify time ranges like:

<date> at <time> for <duration>

So I could say timew track friday at 08:00 for 4h project_a

[xeruf]

The remaining constraint would be that the given times are in the same format, e.g.

timew track 2018-12-12 09:00 - 11am
timew track 2018-12-12 0900 - 11:00

would be invalid.

I don't see the advantage of this constraint. Does it make parsing easier in any way? I'd guess not, you actually have to keep track of the current format. It's not like people accidentally enter a tag that looks like a time either?

[danihodovic]

@lauft if timezone is omitted is local time assumed?

[lauft]

@danihodovic Yes. If the Z is missing, Timewarrior assumes the datetime is given in your system's local time.

[midicase]

Just a suggestion that hopefully would be easier for the parser to process. Use a hybrid ISO format for reporting previous days:

timew track yesterdayT09:00 - yesterdayT11:00
timew track mondayT09:00 - tuesdayT11:00

[smemsh]

fwiw, as a workaround, I'm using a wrapper like this, which helps somewhat:

#!/usr/bin/env bash
: ${1:?}
case ${#1} in
(14) t=$1;;
(10) t=$(date +%Y)$1;;
 (8) t=$(date +%Y%m)$1;;
 (6) t=$(date +%Y%m%d)$1;;
 (4) t=$(date +%Y%m%d%H)$1;;
 (*) echo "need to supply at least minute and second" >&2; false; exit;;
esac
printf ${t:0:4}-${t:4:2}-${t:6:2}T${t:8:2}:${t:10:2}:${t:12:2}

so you can at least specify just the digits (as yyyymmddhhmmss), and the less digits there are, they are taken from the current time, so you can just add a couple digits for yesterday. For example if today is the 13th, you can add a track from yesterday 23:00 to today 3:00 with:

timew track `tfmt 12230000` - `tfmt 030000`

it's a bit less typing (I use this for taskwarrior a lot too, I think maybe the time spec processing is actually implemented in libshared?). Agreed that a native facility would be more handy, however.