fnogatz / clocker

Command-line tool to track project hours
Other
420 stars 31 forks source link

Daily report of logged hours #36

Closed BeniRupp closed 3 years ago

BeniRupp commented 6 years ago

Hey! 👋 I use clocker for logging my daily workload. So for me it would be great to have a report command which lists all logged hours of the current day with a sum of all types and a total sum.

Maybe something like that:

$ clocker report
Today you logged:
1392707136  2014-02-17  [ 23:00:00 - 02:30:00 ]  (03:30:00)  [TypeA]
1392751800  2014-02-18  [ 06:00:00 - 12:00:00 ]  (06:00:00)  [TypeB]
1393020600  2014-02-21  [ 13:15:00 - 17:00:00 ]  (03:45:00)  [TypeA]

TypeA     07:15:00
TypeB     06:00:00

total     13:15:00  

What do you think about this idea? Is there anybody who would be interested in this feature? I think about implementing this feature in the near future and want to collect some feedback. 😉

fnogatz commented 6 years ago

This might be related to https://github.com/substack/clocker/issues/25#issuecomment-94170831.

I went away from the idea of a big refactoring round, and would be happy to welcome small improvements like this.

BeniRupp commented 6 years ago

Okay, cool! So you would prefer a new command like the suggested above?

fnogatz commented 6 years ago

I am open to discuss this :) We are defining more and more different output formats, so maybe it's time to define one route for all. Currently I see the following needs:

They all provide the same modifiers: -t TYPE, --gt DATE and --lt DATE. I have often the need for aggregated values for when using clocker list and clocker data (and not for clocker csv, but there might be people with a need for this, too). Currently, my very own workaround is to pipe clocker json into json tool.

I am in need for aggregates of days, weeks, months, and years. Possible outputs of clocker list with aggregates could be:

$ clocker list
1392707136  2014-02-17  [ 23:00:00 - 02:30:00 ]  (03:30:00)  [TypeA]
1392751800  2014-02-18  [ 06:00:00 - 12:00:00 ]  (06:00:00)  [TypeB]
1393020600  2014-02-21  [ 13:15:00 - 17:00:00 ]  (03:45:00)  [TypeA]
$ clocker list --aggregate day      # or simply --day
2014-02-17  (01:00:00)
2014-02-18  (08:30:00)
2014-02-21  (03:45:00)
$ clocker list --aggregate month    # or simply --month
2014-02  (13:15:00)

Maybe you are more interested in getting the sum grouped by type? Currently you would have to specify -t TYPE. Grouping by TYPE however might be reasonable.

What's your opinion?

BeniRupp commented 6 years ago

I agree with you that same things should handled in the same way, but ... 😉

In my opinion the report command has the following advantages:

  1. it's a concise command
  2. it shows all entries of the day
  3. it shows aggregates of each type
  4. it shows total sum of the day

That means, that I can access the report very quickly without typing to much or writing a script (1). Furthermore I can see all entries of this day and e.g. be able to check whether I have logged all things that I have done (2). The aggregates of each type (3) are important for me, because I have to track them in an external tool. And the total sum of the day is a great overview for me to see what I've worked this day! 💪

If we want to achieve this behavior with the list command, we could probably do something like this:

# All unarchived entries aggregated for a specific day (2018-03-28) and grouped (by type).
$ clocker list --aggregate day --gt '2018-03-28' --lt '2018-03-29' -g
$ clocker list --day --gt '2018-03-28' --lt '2018-03-29' -g

But that is nothing I want to type every afternoon into my terminal. 🙈So maybe even shorter:

# All unarchived entries aggregated for today.
$ clocker list --aggregate today
$ clocker list --today

# All unarchived entries aggregated for a given day.
$ clocker list --aggregate day '2018-03-28'
$ clocker list --day '2018-03-28'

But, the more important thing: This would only list the aggregates of each type. No list of all logged entries of this day and no total hours, since this is not the result we do expect of a list command. We expect a list of values of the same kind, in this case aggregates. Do you agree?

tl;dr: What I need is an overview of several things. A list command lists information of one type of data. That's why I think that these two things should be handled in a different way. Which should not mean that we cannot implement both things. 😉

So, what do you think? Is something like a report command a benefit for this tool? I think it would also be possible to export this report as json and csv to be consistent with current output formats.

BeniRupp commented 6 years ago

@fnogatz can you please give me some feedback?

fnogatz commented 6 years ago

Thank you again for the PR in #37! I have to admit that I was sceptical at first. But once I tried your clocker report command, I never wanted to go back to my daily routine of typing clocker list and clocker data all over again :sunglasses:

Unfortunately, I still have to use my one-liner to keep up with the total hours of a whole week or month (with the help of json):

$ clocker data --gt 2018-06-01 --lt 2018-07-01 | json -a hours | json -a hours | awk '{s+=$1} END {print s}'

I will re-open this issue so we a have a reminder to adapt the new clocker report for more aggregates like week, month or year, or to work with the --gt DATE, --lt DATE options.

fnogatz commented 3 years ago

Merry christmas! Today, one and a half year later, I published version 1.19.0 of clocker, which adds support for --day, --week, --month, --year for all commands that also accept --gt, --lt. In addition, clocker list now also provides the --report flag which results in the exact same output as the daily report of clocker report --reportDay=<value>, which is from now on just a shorter notation for clocker list --report --day=<value>. Together, it is now also possible to call clocker list --week --report to get a list of all entries of the current week with their aggregated sums.

I initially left this issue open as a reminder for this open task to implement other aggregates as well. With v1.19.0 of clocker, this has been resolved, so I'm closing here again :partying_face: