mirror of
https://github.com/GothenburgBitFactory/timewarrior.git
synced 2025-07-07 20:06:39 +02:00
75 lines
4.2 KiB
Text
75 lines
4.2 KiB
Text
Data Files
|
||
==========
|
||
Intervals of tracked time are stored in a text file, with one line of text
|
||
representing one day. Here is a single tracked interval:
|
||
|
||
YYYY-MM-DDTHH:MM - YYYY-MM-DDTHH:MM :: <tagset>
|
||
|
||
Here is an open-ended, currently tracked active interval, notice the missing
|
||
<end> timestamp:
|
||
|
||
YYYY-MM-DDTHH:MM - <tagset>
|
||
|
||
A typical day might look like this:
|
||
|
||
2016-02-28T08:00 - 2016-02-28T12:00 :: Upgrade Planning
|
||
2016-02-28T13:00 :: Upgrade Presentation "ABCD Inc"
|
||
|
||
The first four-hour interval is associated with the tags "Upgrade" and "Planning".
|
||
The second interval is open-ended, and has three tags, the third of which is a
|
||
quoted string because of the embedded space.
|
||
|
||
An open-ended interval that continue into a weekend, remains a single,
|
||
open-ended interval, and does not get flattened into a set of related by distinct
|
||
intervals.
|
||
|
||
|
||
Archiving
|
||
---------
|
||
Automatic data archiving would effectively freeze older data, based on a
|
||
configurable duration, to limit the scope of backfill features and reto-active
|
||
corrections.
|
||
|
||
---
|
||
|
||
If old data is frozen, what does that mean? It should mean that the inclusions and exclusions are collapsed, and the net inclusions recorded and frozen. This prevents changes to the work week from modifying old information.
|
||
|
||
|
||
|
||
F: Regarding the exclusions...
|
||
I just had an idea. Which would help with 3.
|
||
Say we have all the definitions for exclusions.
|
||
These only affect the NOW and the future. Once a day (or time intervall has passed) they are recorded together with the corresponding intervall.
|
||
So in your example with exclusions for monday, tuesday, wednesday and thursday.
|
||
With that they “are” immutable for definition changes. And aren’t rewritten.
|
||
You have to tell timew to change them.
|
||
I would also help in the calculation of the reports.
|
||
P: So if you run “timew define workday end 1745”, then that constitutes a change to the exclusions, and gets recorded in the timeline.
|
||
Then we essentially auto-freeze.
|
||
And we can reconstruct intervals and exclusions perfectly, provided we read the data, in sequence, going back to the previous exclusion change.
|
||
Did I get it right?
|
||
F: Hm. I guess I meant that when you run timew stop tag1 all exclusion definitions affecting the intervall are saved together with the timestamp information of that intervall...
|
||
P: Ah, so every line.
|
||
F: I think so.
|
||
So the line would contain workday start and ends, etc.
|
||
Then you have all exclusion definitions affecting this particular intervall stored together with it.
|
||
P: That is equivalent to doing this:
|
||
on “timew stop”, combine the intervals with the exclusions, and store only the inclusions.
|
||
F: But then you can’t “rewrite” history in case you need. You don’t now which definitions were valid.
|
||
P: True
|
||
So every line in the data contains one interval of recorded time, and all exclusions, even if they don’t change day to day. Because they might change.
|
||
F: Yes. And these would not be affected by redefinitions as they only apply to the future recordings.
|
||
Kind of like saving the “current state”.
|
||
P: Good, I understand it. Nice.
|
||
Zero loss of information.
|
||
F: Then it is just the question when to save them. At the end, when you finish the tracking of that tag? In between as well, when doing redefinitions? Look through open intervalls, recored the current definition that is changed if it affects the intervall.
|
||
I would guess both.
|
||
P: I say both
|
||
F: Cool.
|
||
P: If a redefine occurs in the middle of an interval, stop the first interval and record exlcusions as-is, then add a new interval to continue, but with the new settings.
|
||
Then a redefine just creates two adjacent intervals with different settings.
|
||
Great, [1] and [3] taken care of. [2] archiving...
|
||
Archiving is a feature we could ignore and come to no harm. But if we do archive, to reduce clutter, should it be automatic? ie anything older than a month?
|
||
Archiving also improves performance for “timew stop”, which has less data to scan, when closing an interval.
|
||
F: Automatic would be good. Configurable. Then perhaps an explicite archive. Say you have terminated the work for the client, have sent the bill, got the cash. Then you could tell timew to archive the corresponding entries.
|
||
|