Ability to round when reporting about bartib

[nikolassv]

That sounds like an interesting feature! I could have used it with my previous employers as well. I would more than happy to merge a PR for it. So, please go ahead. Currently, I don't have planned any refactoring that could conflict with the implementation.

[berkes]

Working on it, but I'm running into issues with the way we now pass referenced Activities around.

My idea is as follows:

Right after reading getter::get_activities() we process them. For now, that processing would only be rounding, with a round_activity(&Activity, round: Duration) -> Activity. round_activity returns a new Activity, but with start and end(optional) rounded to nearest Duration. ¹

Processing Activities this early, has as advantage that any calculation, or filter, that follows, uses the rounded values. This way we avoid e.g. filtering for up to 14:15 to e.g. include a entry with, say, end=14:12, but where the rounded value then would show 14:30. That would be weird, not?
Same for calculations, e.g. the totals: they should, IMO, be the sum of the rounded values. Not all values summed and then rounded.

The downside of my approach is that in the current code, all filters, processors, views etc, operate on &'a [&'a Activity], not &'a [Activity]. So the change would be rather big: I'd need to refactor all the references to become values. What do you think of this?

¹ Or better: the issue is that I'm not experienced enough in Rust to find a way to return a referenced Activity that isn't the original Activity

[nikolassv]

Your approach sounds reasonable to me. Incorporating a processing step in the reporting and list commands could also help us with issue #29.

Changing the other functions to work on moved values rather than on borrowed values appears to be a significant change. However, at this moment I don't see what would speak against it.