Timewarrior

[Thomas Lauf]

Hi,

I recently discovered timewarrior when Dirk Deimeke presented
taskwarrior at our company. On first evaluation I find it a pretty nifty
tool which I would try to use for my time tracking. However I really
require one feature, that is setting the granularity of time.

timewarrior tracks time with second precision, I need my times rounded
to the nearest multiple of 3 minutes (some colleagues even to the
nearest 15 minutes). Is this a feature you would consider adding to
timewarrior?

On a first glance, I would wrap the Datetime object used in e.g.
src/commands/CmdStart.cpp:53 by a class which rounds the time according
to the rules passed to it. In the default case it would return the usual
Datetime.

Regards
Thomas

--
Dr. Thomas Lauf * thoma...@tngtech.com * +49 174 3180 086
TNG Technology Consulting GmbH, Betastr. 13a, 85774 Unterföhring
Geschäftsführer: Henrik Klagges, Christoph Stock, Dr. Robert Dahlke
Sitz: Unterföhring * Amtsgericht München, HRB 135082

[Paul Beckingham]

Hi Thomas,

Thank you for hosting Dirk’s talks!

Timewarrior is at release 1.0 and only a few months old, so it is a little light on features and flexibility. Many features were deferred simply to allow a release to occur, so feedback could be generated (such as your suggestion), improving the subsequent releases.

Quantizing time is certainly on the list of features to add. But like every other aspect of time tracking, it is complex. For example, if you were to run this command:

$ timew track 10:01:30 - 10:28:40 “Contrived example"

Then how should it behave in your case? Does the 10:01:30 round down or up? I deliberately put it right in the middle of the three minute block. Does the 10:28:40 round up to 10:30:00? Mathematics would suggest up, in both cases. But there is a case for supporting each of the three possibilities: yours (simply rounding), minimal rounding (round up start time, round down end time), and maximal rounding (round down start time, round up end time).

Your example of a solution would certainly work. But that’s just one command, and there are 27 commands already, so although I would probably do what you suggested, I would make it a validation call before the database write, but not in each of the 27 commands. It is likely the number of commands will increase as well. I’m also trying to keep options open for a planned rule system that could also implement this feature. Young projects are like this - lots for potential but lacking support infrastructure for unanticipated growth. It’s also what makes them fun to work on.

Thank you for telling us!

Paul

> --
> You received this message because you are subscribed to the Google Groups "taskwarrior-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to taskwarrior-d...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[aaronfe...@gmail.com]

This aspect really matters to people who bill for services. The lack of makes timewarrior a no starter for my own use, much to my dismay. I hope that timewarrior is endowed with rounding up of time in the near future.

[Thomas Lauf]

Hi!

> This aspect really matters to people who bill for services. The lack
> of makes timewarrior a no starter for my own use, much to my dismay.
> I hope that timewarrior is endowed with rounding up of time in the
> near future.

When it comes to time granularity, the question is where Timewarrior
should round. When storing to the database or when reporting to the user?

The former would keep everything rather easy as there is only one source
of truth/data, however precision is lost, especially when rounding up to
quarters of an hour or more.

The latter would keep the original data, however may require nifty
strategies when generating reports.

What would happen, if rounding is set to quarters of an hour, but a
point in time is exactly in the middle? Round up or down?

Should Timewarrior always round up/down or should this depend on whether
an interval was opened/closed (i.e. round up at start, round down at stop).

What happens if an interval smaller than the set granularity is
recorded? Round down to 0, round up? What if several of these small
intervals occurr? E.g. rounding is set to 15min, you record three
5-minute intervals. Rounding all up to 15 is not feasible, especially if
you bill for services - or is it?

I would like to hear your thoughts on these. Do you have a specific use
case for your above-mentioned example?

Regards

Thomas

[Ben Boeckel]

Our timetracking software at $DAYJOB seems to round (3 minute blocks) at
the database level. They are only rounded when timers are saved to the
database however (they can be paused which does not induce a rounding
step).

I think this is for conformance with rules about charging government
contracts. I don't know if these rules are public (they probably are,
but I don't know what they're called; I can ask if you'd like), but if a
report could be made which does conform to the rules, it might be enough
for audits.

--Ben