Any interest in a more weekly than daily oriented report?

[sam-github]

https://github.com/sam-github/gtimelog/blob/5a39d38c6057645a7b08af5a7515da5f1b4465a7/src/gtimelog/main.py#L1798-L1813

^-- I run this locally, and I'm fine to keep it as a local manually applied patch against the ubuntu packaged gtimelog, but if its of enough common interest, I could clean it up and PR it.

It does 2 things:

1. Counts the hours I've worked over a week, so that overtime is considered per-week, not per-day. If my target is to work 8 hours for every workday (for example), it shows me how far ahead or behind I am. With the mainline, I have to look at the total hours worked, then subtract (in my head) DaysWorked*8 from it to see if I'm ahead or behind. This is particularly useful for COVID era work from home, where I work in slightly irregular chunks around other responsibilities (as opposed to a 9-5 office day), but want to make sure the total amount of work roughs out to desired hours/day.

2. In the interests of the above, if I check gtimelog at 10pm on a Wednesday night to see how I'm doing, I don't want it counting the hours from my last task at 3pm to now as 7 hours of work time in an unnamed current task. That's why I removed the current task time.

[mgedmin]

This is interesting. I usually look at the per-day average of hours worked this week to see how much I'm ahead or behind.

I'm not opposed to adding weekly computations, but I think it would be better to integrate them into the "Time left at work" row. Maybe. I have to think about it.

BTW there's an (underdocumented?) feature where the time since the last task is not included in the totals if you put a ** in the pending text in the entry box. I wonder if I can make gtimelog smarter about not including this time if you've already reached the expected number of hours today or something like that...

A plugin architecture would be nice for allowing people to play with features like this without juggling patches, but it's work, and I'm burned out. :(

[sam-github]

Yes, even accepting reasonably well-formed patches is a lot of work, I get it, you probably have a life outside gtimelog!

I had to keep doing the math on the per-day average "ok, my average is 7:40, and its the 4th day of the week... hmm, 4 x 20m behind, so when it says I should work until 3pm, I have to work until 4:20pm". I would have lived with it if I had to, but the timelog src is so easy to change (thanks), I just added the exact footer I wanted.

I have no expectations that you will have the time or interest in taking this on... but I wonder if a template string might actually be reasonably easy to achieve?

You kind-of do that already in the code by picking different fmt strings based on the user config, then passing it to wfmt().

If the user could configure the footer template, they could decide exactly what format they want, substituting in the the various pre-calculated values. I'm not so familiar with python template options, but I'm sure there are dozens. If the template allowed arbitrary python expressions, even basic arithmetic would be possible (my weekly is just slightly different math on values that gtimelog has already determined -- days worked, etc.), and many templates allow conditionals, so replicating the parts of code where it shows (for example) hours left in a day if hours was configured non-zero should be easy. The existing code would then ship as the default template.

[mgedmin]

The problem with user-customizable templates is what happens when the upstream introduces a new feature that changes the template? How does every user merge their own customizations with the upstream change? (The answer is "painfully", and I speak from experience.)

Also I don't even want to think how i18n would interact with customizable templates.

Your user story ("I want to say on target to hit a certain weekly hours number") is good, and the only reason I don't want to merge your changes as-is is that I think 4 lines of footer is the maximum number of lines I want to have.

So the new information needs to extend or replace one of the existing lines. The easy way out would be to add a preference (weekly target vs daily target), but preferences have a cost, and I'd prefer not to (no pun intended).

So, I'm thinking

Time left at work: X h Y min (till HH:MM), or X h Y min (till HH:MM) if you want to hit the weekly target

which is a bit long. Can you suggest a more concise wording?

[sam-github]

re: preferences, that's one point of view, the other is that not everyone has the same wants. I found the slacking distracting, because picking my kids up from school isn't actually "slacking", and even if it was, I only care that I spend enough time working. I removed that (which is one way to keep to 4 lines).

My display looks like this ATM:

Total work done: 0 h 21 min (32 h 59 min this week, 6 h 35 min per day)

Weekly time left: 4 h 31 min (till 12:31)

When there is overtime:

Total work done: 0 h 0 min (32 h 38 min this week, 8 h 9 min per day)

Weekly overtime: 2 h 38 min

If it was packed into one line, perhaps: Time left per-day: ..., Time left per-week: ...? Plus some kind of alternative for when there is overtime?

[mgedmin]

(The term "slacking" is a bad joke and I regret it. I'd change it if I could come up with an alternative.)

[bartkl]

Great discussion!

There's one thing I don't understand: how does gtimelog know how many hours per week I work? Or (perhaps equivalently) how does it know on which days of the week I work?

The point for me being that I perform work on differing days of the week. I'm afraid my use case would require a lot more changes, wouldn't it?

[mgedmin]

gtimelog checks the log to see which days have entries. All the average time / day computations use that number. This does mean that if you quickly did a 5 minute urgent hotfix on a Sunday, the averages become off, but such is life.

[jpsnyder]

For what it's worth I would like it if we could have a report that has a breakdown of hours worked for each day of the week.
For me, at the end of the week I need to manually transfer my hours from gtimelog to our company's timesheet software. It requires putting in the hours worked per day with the right billing codes (tags in gtimelog).

I'd imagine this is a common scenario for peopl. So having a weekly report split up by day would be nice.

[mgedmin]

I used to use the history browsing for this (manually synchronizing timesheets with Jira): hit Ctrl+F, type the project prefix for filtering out irrelevant entries, then keep hitting Alt-Left and looking at the total time at the bottom for every day.

Nowadays I use a script a coworker wrote to parse timelog.txt and import it to Jira using Jira's API: https://github.com/ProgrammersOfVilnius/gtimelog2jira

[jpsnyder]

That's actually what I do now. It works well enough, just wasn't sure if there would be any interest in making such a report.
(Perhaps allow users to make their own custom report using a templating system such as Jinja?)

Funny enough I wrote a similiar script for Toggl just to import my entries to create a weekly report, until I realized this simpler technique. (https://github.com/jpsnyder/gtimelog2toggl)