RFC: time span syntax within timedot

39 views
Skip to first unread message

Alex Hirzel

unread,
Jun 28, 2022, 4:22:10 PM6/28/22
to hledger
Hello, and thanks to all contributors for making such an awesome piece of software!

I am trying to switch from a home-brewed timekeeping system to hledger. In short, I am wondering what the community appetite may be for a change that allows the following to parse correctly in a timedot file:

2022-06-28 description
Time:ABC:Task1  8.2-8.9 ; comment 1
Time:ABC:Task1  9-10.3 ; comment 2

Using this syntax, the duration associated with each line is computed by subtracting the two numbers (8.9 - 8.2 = 0.7 or 10.3 - 9 = 1.3). The default time unit is applied just as if the hour count itself (0.7 or 1.3) had been written instead. The primary advantage is that I can use a 24-hour timestamp for start and end times, and I can leave a "hanging entry" while I'm working. It also makes a 6-minute rule very easy to observe by using zero or one decimal place everywhere, and is also less verbose than the timeclock format for this use case.

(The syntax I'm proposing is inspired by a note-taking system I cobbled together many moons ago to parse Markdown a la:

## 2022-06-28
I think I need to verb the noun today!
```timekeeping
8.2-8.9 Task1 - comment 1
9.0-10.3 Task2 - comment 2
```
Okay, that didn't work so well. New plan: lorem ipsum ...

The legacy system I'm depreciating pulls out the inline timekeeping blocks and does basic reporting.)

Appreciate any feedback, and/or an indication that a PR would be welcome to support the timedot syntax (already have it working locally, just need to do documentation work prior to PR). If there is interest in the system that I'm killing off, I'm more than happy to explain further and/or to mock up a new reader.

Alex

Simon Michael

unread,
Jan 12, 2023, 8:15:05 PM1/12/23
to hledger
Hi Alex.. belated reply, I'm sorry you didn't get one back then. 

The syntax looks neat and useful. The decimal times seem a little idiosyncratic, maybe not everyone would like that. Would it also allow HHMM[-HHMM] ?

You could shoehorn it into timedot format, like I did with allowing numbers there. But it stops being a simple reimplementable "timedot" format at some point.

Semantically, it seems a little closer to timeclock format. Would a good way to experiment be to make a script that transforms your format to timeclock, then you could pipe that into hledger for reporting ? Perhaps you already did something like this.

Happy 2023!
-Simon

Alex Hirzel

unread,
Jan 12, 2023, 8:28:38 PM1/12/23
to hledger
Simon, thanks for the reply and reminder. There was some discussion of this on GitHub, and I believe we arrived at the conclusion that I would make my own format or make a transformer exactly as you recall. As life goes, however, I have been short on time and am running a local fork to parse my "production prototype" file format pending having the time to switch everything over :(

For posterity, relevant prior discussion: https://github.com/simonmichael/hledger/pull/1878

I was also going to make some other timedot changes as an opportunity to learn the data structures: https://github.com/simonmichael/hledger/issues/1754

The latter is still outstanding. Happy and safe 2023 to you as well, and thanks for your work on hledger!

Alex

Simon Michael

unread,
Jan 12, 2023, 8:42:15 PM1/12/23
to hledger
Ah, good. Thanks!



--
You received this message because you are subscribed to the Google Groups "hledger" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hledger+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hledger/1b8b794a-7609-41c9-b14d-a73628046ca5n%40googlegroups.com.

Reply all
Reply to author
Forward
0 new messages