Open lauft opened 5 years ago
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.
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.
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!
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
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?
@lauft if timezone is omitted is local time assumed?
@danihodovic Yes. If the Z
is missing, Timewarrior assumes the datetime is given in your system's local time.
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
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.
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.
Resolving this issue will still be very valuable.
6g s34.
On Tue, Aug 13, 2024, 4:52 AM Grové Steyn @.***> wrote:
Entering time intervals for a previous day is currently very cumbersome. Typing in long dates are prone to typos. The suggestion above by @lauft https://github.com/lauft would make a huge difference.
Resolving this issue will still be very valuable.
— Reply to this email directly, view it on GitHub https://github.com/GothenburgBitFactory/timewarrior/issues/196#issuecomment-2286062819, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEH467ZLWLH2LGMR4OPWHDZRHXPJAVCNFSM6AAAAABMODHYVCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBWGA3DEOBRHE . You are receiving this because you commented.Message ID: @.***>
Make specification of datetime ranges more flexible. Currently only datetimes in ISO format or simple times are allowed:
It should be possible to specifiy datetime ranges also as
<date> <time> - <time>
, e.g.The remaining constraint would be that the given times are in the same format, e.g.
would be invalid.