timetracker

tblancher's CLI-based time tracking system

This framework is what I use to keep track of my time, as I work. Only one task is allowed concurrently, so if I switch to another task, I must end the current task before proceeding. This is tracked in a log file following format:

log file format

2017-12-08 08:59:06:  Begin internal task 1
2017-12-08 09:10:55:  End   internal task 1
2017-12-08 09:10:56:  Begin internal task 2
2017-12-08 09:15:14:  End   internal task 2
2017-12-08 09:15:14:  Begin [Customer 1] task 1
2017-12-08 09:19:52:  End   [Customer 1] task 1
2017-12-08 09:19:52:  Begin [Customer 1] PDROP-0000000 incident-related task 1
2017-12-08 09:27:37:  End   [Customer 1] PDROP-0000000 incident-related task 1
2017-12-08 09:27:38:  Begin [Customer 2] task 2
2017-12-08 11:00:39:  End   [Customer 2] task 2
2017-12-08 11:00:40:  Begin [Customer 1] PDROP-0000000 incident-related task 2
2017-12-08 11:07:24:  End   [Customer 1] PDROP-0000000 incident-related task 2
2017-12-08 11:08:56:  Begin internal task 3
2017-12-08 16:55:43:  End   internal task 3

The timestamp is in most-to-least significant units, though any valid date and time should work (however, any other format is untested. BEWARE!). The separator between the timestamp and the Begin or End keywoards is : , literally a colon followed by two spaces. Anything else will break timetracker.py, and the rest of it will fall down. Each task must have a Begin and End line, or else the output of timetracker will not be correct. Too many begins or ends should be detected by timetracker.py. The name of the task is free form, and must be identical for the Begin and End (otherwise timetracker.py will think they're different tasks).

Certain strings have special meaning to timetracker.py. The customer name in square brackets specifies that the task is related to a specific customer, to make tallying in Clarizen more straightforward. These can be any string, even with spaces, but beware of using shell special characters. The names can be anything, so things like [Citi], [Wells Fargo], or [CS Support].

timetracker.py usage

The timetracker.py script is the basis, it tallies the time for each task and then outputs a report on how much each task takes to complete. It takes as its argument one or more text files, the log files in the format above. It should only report one line item per task, regardless of how many times it appears in the log. Note that each task now gets rounded up to the nearest quarter hour (15minutes). The output looks like this:

timetracker output

[Customer 1] PDROP-0000000 incident-related task 1    0.25hrs
[Customer 1] PDROP-0000000 incident-related task 2    0.25hrs
[Customer 1] task 1                                   0.25hrs
[Customer 2] task 2                                   1.75hrs
internal task 1                                       0.25hrs
internal task 2                                       0.25hrs
internal task 3                                       6.00hrs

Section total:            28502s    9.00hrs

do_process

This script filters the output of timetracker.py, giving each organization (in square brackets) its own section, with its own tallies. This is designed to be directly transferred to Clarizen manually. It calculates the time total for each organization/category, plus anything uncategorized. At the end it prints a grand total for the day, which should be used to cross-verify in Clarizen.

It takes as its argument a filename with the current date (date +%F format), or it assumes the current date log file.

chug

This script is designed to be run on Mondays, after the previous week of log files have been generated and closed out. The standard Monday usage takes no arguments, it expects all log files to be processed to be in the current directory. It runs do_process once for each day of the previous week, cleanly skipping any log files which do not exist. It pauses after each day report is output, allowing the user to transfer the times manually to Clarizen.

chug takes a single optional argument, a week offset (in case chug is executed for log files further back than last week). This uses the GNU date functionality of calculating "last Monday." On Monday this will be "today - 7 days", but on the following Tuesday this will evaluate to "yesterday". If Monday is a holiday and you're entering your timesheets on Tuesday you can enter chug 1 and it should do the right thing. chug with no arguments is equivalent to chug 0.

month-pack.sh

timetracker.py and the related do_process and chug scripts are designed to have each day with its own YYYY-MM-DD.log file in the current, timetracker directory. Over time, the log files in this directory can become quite numerous and unwieldy. To help combat this, month-pack.sh takes all the log files from the previous month, adds them to a compressed tarball, and deletes them from the directory. It is designed to be run once all of the log files for the previous month have been processed.

year-pack.sh

In the same vein as month-pack.sh, year-pack.sh tars up all the monthly tarballs (named YYYY-MM.tar.xz), and puts them into a single YYYY.tar file. It is designed to be run in January when all of the previous December log files have been processed. All of the YYYY-MM.tar.xz files will be deleted once the YYYY.tar file is created.