Dirk Deimeke on 2016-06-26T07:08:15Z says:

Weekstart is handled differently across the world and calendar weeks as well.

Michel Crucifix on 2016-09-04T21:10:16Z says:

maybe a bug ? If I ask

timew summary :lastweek

on a Sunday, it gives me a summary for the previous two weeks.

Perhaps the command timew help xxx would return a subset of relevant help, if possible, not just the standard documents.

Tomas Babej on 2016-06-04T17:04:23Z says:

The month report truncates the bar for the current task to the width of the bar representing the current day, even if the task has been running for multiple days.

As a result, the total column also gets skewed off.

Yury Vidineev on 2016-08-01T21:36:00Z says:

I'm not sure if it's should. Please close issue if I'm not right

$ timew track 9:30am to 10:00am 'meeting'
Unrecognized date range: ' to'.

$ timew track 9:30am to 10am 'meeting'
Recorded "Version meeting"
Started 2016-08-01T09:30:00
Ended 10:00:00
Total 0:30:00

Jonathon Bly on 2016-07-26T03:16:04Z says:

Even though I have configured a work week according to the online documentation, I am not seeing the blocks displayed on the report. It is correctly counting available time, so I assume all the math is correct. Just a display issue.

Dennis Schubert on 2016-07-26T09:32:19Z says:

It would be useful if we could continue a tracking by using the ID, since people often switch between tasks:

{code}
timew continue @2
{code}

Yury Vidineev on 2016-08-01T21:21:12Z says:

If there are no such option in config 'timew config' doesn't try to add it (as opposite and expected: 'task config' can do that ).
For example:
My config file is very simple:
$ cat ~/.timewarrior/timewarrior.cfg
import /usr/local/share/doc/timew/doc/holidays/holidays.en-US

I'm trying to add option:
$ timew config reports.day.lines 4
No changes made.

Is it expected behavior? I expected something like this:

$ task config reports.day.lines 4
Are you sure you want to add 'reports.day.lines' with a value of '4'? (yes/no)

P.S. Sorry for my English

Salut,

is adding syncing via taskserver on the roadmap/in the scope of this project?

Cheers,
Igor

Michael Meier on 2016-09-10T11:12:17Z says:

Have a look at the attached screenshot. Even though the current day only has entries until 13:01, the day report has the remaining day filled with pysoase tools. The same happens in the week and month reports.

Note that the numbers in the summary report as well as the Tracked number for the day tools report are correct, I spend about an hour on a tools task today. But still, the charts seem to fill the entire day with that task.

Perhaps there is a problem because the 00:00:00 - 00:00:54 entry is too short?

Currently a brief summary of an active interval is displayed when the command timew is entered. This could be configurable, so that other commands could run.

Yury V. Zaytsev on 2016-08-23T17:32:18Z says:

It would be awesome if Timewarrior supported time budgets / accounts.

One should be able set the available budget for a specific tag e.g. to 8 hours per day every workday. The balance will then be automatically increased by 8 hours every workday and decreased by the time logged to this tag. Summary reports should show the current balance & logged time for the tag.

It is also important to be able to define holidays / vacations, etc. so that on these days, the balance doesn't auto-increment. It would be nice to be able to set starting and ending time points for the auto-increment function.

Jelle van der Waa on 2016-09-03T15:53:37Z says:

When downloading the holiday events for nb-NO the script throws an error about ascii encoding.

[jelle(at)starfigther][/tmp/timew/trunk]%/usr/share/doc/timew/doc/holidays/refresh --locale nb-NO
http://holidata.net/nb-NO/2016.json
Error: 'ascii' codec can't encode character u'\xe5' in position 21: ordinal not in range(128)

Sebastian Uharek on 2016-05-27T08:57:37Z says:

When creating a task with

1. times start 'test
   '

(newline was not intentional) this creates a line containing just " in the database. All subsequent calls of time warrior fail with:

Unrecognizable line '"'.

until the line is deleted

Tomas Babej on 2016-06-12T14:54:01Z says:

Only the last interval of the day is being displayed.

Reproducer (in the UTC zone):

inc 20160603T040000Z - 20160603T070000Z # interval1
inc 20160603T080000Z - 20160603T120000Z # interval2

lumbric on 2016-06-23T13:49:16Z says:

I think it would be very useful to allow:

timew tag my_new_tag

That means that this...

timew start my_first_tag
timew tag my_second_tag

...would be equivalent to:

timew start my_first_tag my_second_tag

Currently calling without is not supported:

$ timew help tag
Syntax: timew tag @<id> [@<id> ...] <tag> [<tag> ...]

Frédéric Meynadier on 2016-09-05T08:39:39Z says:

As discussed in https://groups.google.com/forum/#!topic/taskwarrior-dev/KoOxlr30ZXc , this is a suggestion to implement a two-way integration with Taskwarrior.

Currently, "task 42 start" makes the task active in Taskwarrior and starts tracking it in Timewarrior thanks to the appropriate hook. "task 42 stop" makes it inactive, and stops timetracking.

But it would also seem natural that "timew stop" stops timetracking in Timewarrior (which it does) and switches the currently active task to "inactive" in Taskwarrior, provided there's no ambiguity (which should be the case as long as we don't have overlapping tags). This would avoid the need to provide a task ID.

In the discussion, Paul states that an appropriate way to implement it will be the foreseen "rules" mechanism.

lumbric on 2016-06-29T08:16:38Z says:

Following commands should not change the ids nor the sorting order of activities in summary: lengthen, shorten, tag and untag

More difficult how to deal with: join, move, remove/delete

(There is no delete/remove yet.)

Aaron Curtis on 2016-06-28T16:36:05Z says:

I only intend to use timewarrior with taskwarrior, so I installed the hook and called "task start mytask", which results in this error:

ERROR: Configuration file not found.
Hook Error: Expected 1 JSON task(s), found 0

Took me a few minutes to realize I need to call "timew" and create the timewarrior configuration file before I can use the taskwarrior hook. This is fairly obvious but you could save time for silly new users like me if the hook itself would create the config file for you, just as calling "timew" does.

Sergey Trofimov on 2016-06-08T13:31:44Z says:

scenario:
start a
stop b
outcome:
stop b command should be ignored, because tag b is not active

❯ timew start a
Tracking a
  Started 2016-06-08T16:36:31
  Current                  31
  Total               0:00:00
❯ timew stop b
Recorded a
  Started 2016-06-08T16:36:31
  Ended                    36
  Total               0:00:05

Tracking a
  Started 2016-06-08T16:36:36
  Current                  36
  Total               0:00:05
❯ timew
Tracking a
  Started 2016-06-08T16:36:36
  Current                  40
  Total               0:00:09

lumbric on 2016-06-23T12:51:32Z says:

It tells me "Specify which report to run" when I try to run the report command:

{code}
$ timew report csv
Specify which report to run.
{code}

I copied the extension files myself from the repository to ~/.timewarrior/extensions and they are found correctly by timew:

{code}
$ timew extension

Extensions located in:
/home/[snip]/.timewarrior/extensions

Extension Status
README No executable
csv.py Active
debug.py Active
on-modify.timewarrior Active
{code}

{code}
$ timew diagnostics

timew 0.9.5.alpha
Platform: Linux

Compiler:
Version: 4.7.2 20130108 [gcc-4_7-branch revision 195012]
Caps: +stdc +stdc_hosted +LP64 +c8 +i32 +l64 +vp64 +time_t64
Compliance: C++11

Build Features
Built: Jun 22 2016 13:24:12
CMake: 2.8.10.2
Build type: release

Configuration
TIMEWARRIORDB: -
Cfg: /home/[snip]/.timewarrior/timewarrior.cfg (-rw- 0 bytes)
Database: /home/[snip]/.timewarrior (drwx 56 bytes)
Color theme: Default theme
00 01 02 03 04 05 06 07 08 09 10 11 12

Extensions
Location: /home/[snip]/.timewarrior/extensions (drwx 75 bytes)
/home/[snip]/.timewarrior/extensions/README (-rw- 465 bytes)
/home/[snip]/.timewarrior/extensions/csv.py (-rwx 456 bytes)
/home/[snip]/.timewarrior/extensions/debug.py (-rwx 79 bytes)
/home/[snip]/.timewarrior/extensions/on-modify.timewarrior (-rwx 2089 bytes)
{code}

David Patrick on 2016-06-30T05:18:47Z says:

new command 'timew edit [date]' would allow users to easily edit the current timewarrior data file. if [date] is used, the applicable data file would be opened (with your default application, especially if that's vim)

Michael Meier on 2016-06-21T20:48:58Z says:

(Version is the 0.9.5 Alpha, which is not in the "Affects Versions" dropdown.)

Id's displayed with the "timew sum :id" command are not correct when the last change was made for an interval on the previous day. To reproduce, enter the following commands (might need to be altered so first and third interval are on previous day and second interval is on current day):

{code}

timew track 2016-06-20T19:48 to 2016-06-20T20:15 "Test 1"
timew track 2016-06-21T20:47 to 2016-06-21T21:10 "Test 2"
timew track 2016-06-20T21:48 to 2016-06-20T22:00 "Test 3"
timew summary :id

Wk Date Day ID Tags Start End Time Total
W26 2016-06-21 Tue @1 Test 2 20:47:00 21:10:00 0:23:00 0:23:00

                                                   0:23:00

timew summary :id monday

Wk Date Day ID Tags Start End Time Total
W26 2016-06-20 Mon @3 Test 1 19:48:00 20:15:00 0:27:00
@1 Test 3 21:48:00 22:00:00 0:12:00 0:39:00
W26 2016-06-21 Tue @2 Test 2 20:47:00 21:10:00 0:23:00 0:23:00

                                                   1:02:00

timew summary :id

Wk Date Day ID Tags Start End Time Total
W26 2016-06-21 Tue @1 Test 2 20:47:00 21:10:00 0:23:00 0:23:00

                                                   0:23:00

timew lengthen @1 12sec

timew summary :id monday

Wk Date Day ID Tags Start End Time Total
W26 2016-06-20 Mon @3 Test 1 19:48:00 20:15:00 0:27:00
@1 Test 3 21:48:00 22:00:12 0:12:12 0:39:12
W26 2016-06-21 Tue @2 Test 2 20:47:00 21:10:00 0:23:00 0:23:00

                                                   1:02:12

{code}

The expectation would have been that the interval denoted with id "1" in the most recent report, the "Test 2" interval, would be lengthened by 12 seconds. Instead, the "Test 3" Interval was lengthened.

Paul Beckingham on 2016-04-08T12:30:48Z says:

Add an undo command, and the associated transaction log to provide the data.

Tomas Babej on 2016-06-12T14:55:47Z says:

In the month report, if the tasks spans over the whole day, the summand in the 'total' column shows only 23:59, instead of 24:00. The total resuting sum, however, is correct.

David Patrick on 2016-09-07T04:46:42Z says:

Related to $TIMEWARRIORDB environment variable, rc:path/to/db would allow inline redirect to alternative data and configs.

User Frédéric Meynadier suggested an interruption feature, where an open interval could be interrupted temporarily by a new interval. It might work like this:

$ timew start ORIGINAL_WORK
...
$timew interrupt EMERGENCY_WORK
...
$timew stop
...
# ORIGINAL_WORK interval resumed

A new tag could be an indicator of a spelling mistake, and a warning could be useful. It should be configurable.

This feature was added in the past and then removed because it was implemented at the DB level, and the "modify" API call performed a "delete" then "add" call, which triggered a false positive for this warning.

Jan Stolarek on 2016-09-01T20:46:26Z says:

Exclusions don't play nice with reports.week.hours=auto. In my configuration file I have defined:

exclusions.monday    = <8:00 >22:00
exclusions.tuesday   = <8:00 >22:00
exclusions.wednesday = <8:00 >22:00
exclusions.thursday  = <8:00 >22:00
exclusions.friday    = <8:00 >22:00
exclusions.saturday  = >0:00
exclusions.sunday    = >0:00

Now even if I use reports.week.hours=auto in my configuration file I still get hours displayed from 0 to 23. I think exclusions should be ignored in this case - they are not tasks that should be displayed.

Jan Stolarek on 2016-09-01T20:05:03Z says:

When I pass a bogus string as value of rc.reports.week.lines I get a segfault:

{code}
[killy(at)GLaDOS : ~] tw week rc.reports.week.lines=foobar

       0    1    2    3    4    5    6    7    8    9    10   11   12   13   14   15   16   17   18   19   20   21   22   23     Total

Segmentation fault
{code}

Paul Beckingham on 2016-07-03T14:35:45Z says:

:quarter should evaluate to the current quarter, and ::lastquarter to the one before that. They are instead the same.

Jonathon Bly on 2016-07-26T03:17:29Z says:

The named blocks of time in the day report are written over the hours of the day. This problem is not present in the week report.

It is not possible to easily set up exclusions for someone who doesn't work alternate fridays, for example.

Michael Meier on 2016-08-21T16:38:51Z says:

There is no longer any warning displayed when a new tag is used.

Example:

timew start "A test" testing
Tracking "A test" testing
  Started 2016-08-21T18:26:23
  Current                  23
  Total               0:00:00

Expected:

timew start "A test" testing
Tracking "A test" testing
  Started 2016-08-21T18:26:23
  Current                  23
  Total               0:00:00
New tags: "A test", testing added

It seems the feature got lost somewhere between the resolution of Issue TI-14 and the release.

Matthias Rieber on 2016-06-24T08:20:58Z says:

I think it would be nice to have a warning when a new tag is added to avoid typos like:

$ timew start meeeting
WARNING new tag: meeeting \[y/n\]

Paul Beckingham on 2016-07-04T11:32:18Z says:

If a single interval is opened on day 1, then on day 2, with no further activity, timew will crash with:

Error: Memory allocation failed: std::bad_alloc

Exclusions are likely involved.

lumbric on 2016-06-29T08:19:04Z says:

There is a cancel command, but currently there is no way to remove a tracked activity (via id).

I am imagining something like:
timew delete @ [@ ...]

or:

timew remove @<id> [@<id> ...]

Paul Kishimoto on 2016-08-19T21:02:21Z says:

Really excited to see this reaching beta, I coded [an extension|https://gist.github.com/khaeru/860b60a4e42420fe35f70b7a98294f6e] to import data from [Toggl|http://toggl.com] using its [API|https://github.com/toggl/toggl_api_docs].

I found that the Toggl API returns dates in the format 2016-01-07T23:59:38-05:00. This was consistent with the "extended date/extended time" format [described in the Timewarrior documentation|https://taskwarrior.org/docs/timewarrior/dates.html], so I used the Toggl dates directly when writing entries to the datafiles. Timewarrior silently fails to report these entries.

E.g. with the following in 2016-08.data:

inc 20160816T202045Z - 20160816T202053Z # "Sample activity"
inc 2016-08-16T20:20:50-04:00 - 2016-08-16T20:20:59-04:00 # "Another sample activity"
inc 20160816T202050-0400 - 20160816T202059-0400 # "A third sample activity"

then:

$ timew summary 2016-08 :debug
CLI Parser
  _original_args
    timew summary 2016-08 :debug
  _args
    word basename='timew' raw='timew' BINARY 
    word canonical='summary' raw='summary' ORIGINAL EXT 
    date raw='2016-08' ORIGINAL FILTER 
    word canonical=':debug' raw=':debug' ORIGINAL HINT FILTER 

>> 2016-08.data: 3 intervals
>> Found 0 holidays
>> Found 0 exclusions
>> Loaded 3 tracked intervals

Wk  Date       Day Tags               Start      End    Time   Total
W33 2016-08-16 Tue Sample activity 16:20:45 16:20:53 0:00:08 0:00:08
                                                                    
                                                             0:00:08

>> Timer timew 0.058759 sec

It reports loading 3 intervals, but only reports the one with the date format 20160816T202045Z.

IMHO it's fine if the data file format only accepts one time format, but this should be mentioned in the extension docs.

Frédéric Meynadier on 2016-07-12T13:22:34Z says:

The taskwarrior hook "on-modify.timewarrior" raises an UnicodeEncodeError with tasks containing UTF8 characters.

A (one-line) patch has been posted by M. Boeker , see
https://groups.google.com/forum/#!topic/taskwarrior-dev/joW2PQfb3T0

After having applied it I can confirm that it works, please consider integrating it : it just encodes the tag correctly (and strips leading/trailing whitespaces). This will probably not be necessary any more once the switch to python3 is done, but it the meantime it will do the job...

Thanks,

Frédéric Meynadier

With Github and the pull request model, the CONTRIBUTING.md file is probably not needed, or could be reduced.

Yury Vidineev on 2016-08-06T01:16:32Z says:

Hi
Just an idea. If task in taskwarrior moving to waiting state - stop tracking it.

$ task add test task
Created task 53.

$ task 53

Name Value
ID 53
Description test task
Status Pending
...

$ task 53 start
Starting task 868ba8ce-cd7e-45fc-8844-29ecfa152e7f 'test task'.
Started 1 task.
Tracking "test task"
...

$ task 53 mod wait:monday
Modifying task 53 'test task'.
Modified 1 task.

But timewarrior is still recording such task. I think it will be good to stop recording.

Thanks for your work :)

Tomas Babej on 2016-06-06T10:09:27Z says:

Timew will report no active tracking for this data file:

inc 20160605T233522Z
inc 20160605T214945Z - 20160605T234945Z # oss

$ timew
There is no active time tracking.

Paul Kishimoto on 2016-08-19T21:17:02Z says:

Also related to [this extension|https://gist.github.com/khaeru/860b60a4e42420fe35f70b7a98294f6e], Toggl reports a unique ID for every entry. At first, I had the extension write these as a tag like toggl_id:ID. But I found this prevented Timewarrior from grouping these intervals together for reporting.

I also use a variation on the [on-modify.timewarrior hook|https://git.tasktools.org/projects/TM/repos/timew/browse/ext/on-modify.timewarrior] for Taskwarrior that adds a tag like uuid:<UUID> to Timewarrior intervals. In this case, the UUID is useful for later matching, especially if the task description is changed in Taskwarrior; but it would be useful to be able to omit it from Timewarrior displays.

Perhaps:

• Tags beginning with _, . or some other special character could be hidden and/or ignored when reporting, and/or
• A configuration option like tag.<tag>.ignore = yes could be added.

Felix Wolfsteller on 2016-08-12T06:30:57Z says:

The timew-binary should respond to '--help' as it does to 'help' to match users (okay... my) expectations.

Furthermore, a bare and uninitialized timew should hint you to the help command in its default output instead of just saying that nothing was recorded yet.

Sergey Trofimov on 2016-06-06T15:02:18Z says:

I have enabled debug in cfg and bisected bug using

git bisect run sh -c 'cmake . && make && ./src/timew stop тест | grep тест'

Bug was introduced in revision
e910506

Seems, that you treat unicode string as bytes when removing control characters from it.

Aaron Fields on 2016-07-11T12:38:19Z says:

When exclusions are used to implement 'working hours', timew will display time spent on a task properly even if the task wasn't "stopped". However, the 'export' command does not seem to take the exclusions in to consideration, which means that tasks overlapping an exclusion boundary will have no 'end' value in the exported JSON.

Maybe this is intentional -- however, it is causing some issues for me with some wrapper scripts I'm developing for personal timekeeping while working. Namely, my scripts are relying upon the output of 'export', and I am using 'exclusions', but since 'export' doesn't take exclusions in to account, my scripts think that some tasks have no 'end' time/date.

Maybe this is an intentional design choice -- if that's the case, then I'll work in implementing a workaround in my scripts. Please let me know if you have any questions and/or need any additional information.

Thanks!

Jan Stolarek on 2016-09-01T20:38:43Z says:

I installed totals extension as described in the tutorial but when I try to run it it fails with an error:

{code}
[killy(at)GLaDOS : ~] timew totals
Traceback (most recent call last):
File "/dane/uczelnia/inne/.zadania/extensions/totals.py", line 74, in
for tag in object['tags']:
KeyError: 'tags'
{code}
/dane/uczelnia/inne/.zadania/ is my custom location for timewarrior data. It already contains some entries:

{code}
[killy(at)GLaDOS : ~] timew summary
Wk Date Day Tags Start End Time Total
W35 2016-09-01 Thu Foo, dom 10:38:19 10:43:00 0:04:41
Foo, dom 10:43:14 10:43:51 0:00:37
Foo, dom 10:44:10 10:44:19 0:00:09
Foo, dom 12:35:42 13:05:01 0:29:19
Foo, dom 13:12:40 13:13:13 0:00:33
13:13:16 13:13:27 0:00:11
13:13:29 13:13:30 0:00:01
13:13:32 13:24:17 0:10:45
Bar, dom 14:06:16 15:35:29 1:29:13 2:15:29

                                                   2:15:29

{code}

Paul Beckingham on 2016-07-01T11:37:11Z says:

The week number in Timewarrior and Taskwarrior do not agree. One of them is wrong.

Thanks to Dirk Deimeke.

Sergey Trofimov on 2016-06-08T09:15:00Z says:

Shortening for a period greater than interval length causes exception.
Steps to follow:

❯ timew summary :ids yesterday   
                   @1  afk toilet, ffd74312-4912-4b46-a2b4-96d9d41b23a6                                     11:09:27 11:12:17 0:02:50 1:12:46

❯ timew shorten @1 5min 
Shortened @1 by 0:05:00

❯ timew summary :ids yesterday          
timew: /home/sarg/devel/timew/src/Range.cpp:326: time_t Range::total() const: Assertion `is_open () || end >= start' failed.
[1]    27820 abort (core dumped)  timew summary :ids yesterday

Tomas Babej on 2016-06-12T14:57:38Z says:

See attached picture for illustration. Any data file containing at least one interval can reproduce this.