timesheet.txt
timesheet.txt copied to clipboard
scy
Does every day have to end with a stop?
Reading a bit more, entries should be able to span days, so presumably yes. In this case all hours should be counted I guess.
So I am trying to count all hours in a day, with a missing stop entry I should just count until midnight. And for the next day I need to count from midnight until next stop entry.
I like your issues, they show me where to focus on when writing the spec. ;)
The fact that entries are organized in "blocks" preceded by a date line is pure convenience, so that you don't have to write the date in front of every timestamp. Internally, these blocks should have no significance.
Basically, you can imagine a 2019-08-03: line as saying "hey, this is the date prefix for every timestamp that's coming up". Keep it in a variable in your parser and prepend all the timestamps with it.
Entries can be stopped in exactly two ways:
- By another entry starting.
- By an explicit stop line.
If a "day block" ends without a stop entry, the last of its entries will continue on until the next entry starts, an explicit stop line occurs or the file ends. If the file ends with a running entry, the implementation must consider it "still running". Whether a "still running" entry is displayed differently, ignored (e.g. for reports) etc. is up to the implementation. There can only be zero or one running entry.
If you simply handle entries as having a start and an end timestamp, your programming language should have means to tell you how long that interval is (in seconds, hours, whatever), no matter how many days the entry spans, if any.
Of course, if you'd like to know how many hours you've worked on a particular day, and the last entry on that day spans multiple days, you'll have to introduce a "virtual" stop at midnight in whatever timezone is currently in use, yes.
By the way, since the date lines are simply prefixes for the timestamps, in my opinion it should be legal to write a file like this:
2019-08-03:
1234 foo
2019-08-03:
2345.
And possibly even
2019-08-03:
1234 foo
2019-08-01:
# This is two days earlier, but since there's no entry on that date, it will be ignored.
# If this day had an entry, it would be considered breaking the ascending order of
# the file, which is an error.
2019-08-03:
2345.
Hehe, thats good :)
Hm, while still possible to solve, this introduces a bit of complexity for the implementation: if I try to collect all entries per date I need to do a lookup every time I encounter a new date line. It also means that if I want to retro-actively edit a previous day I may have multiple choices for where to add that data (in addition to just a new date block for self-contained time-segments). Emtpy dates, do not introduce any problem, but I do not see how a date block splitting a date (like your last example) is used for anything else than planning or diary.
In my opinion it would be better to edit the previous date block, rather than opening a new one. And thus putting a hard requirement on date blocks also always increasing. This would make a much more structured (less entropy) file, at the cost of having to modify entries mid-file (which one would probably still have to support).
If dates are not ordered, then the entries are not sorted, and any computation to be made has to load the entire file. Additionally even if the file is loaded anyway, it must be sorted and resolving time segments become more difficult.
It would also mean that if part of the file gets damaged or is missing then you would no longer know if you have complete entries for the rest of the file.