Feature Request: Add tags

[DeflateAwning]

I want to be able to add tags like "location:office" or "location:home" to tag where I worked from for each time tracking entry. Is that a feature you're able to consider adding? The tags would be arbitrary, of course

[nikolassv]

Thanks for the suggestion! I think I would consider such a feature if it integrates well with current file format and the application, overall. If we can add tags to activities, it should also be possible to filter lists and reports by tags. We should also have a command to list all currently used tags

[DeliciousHair]

I came here to make the same suggestion in fact. I'm guessing this feature does not yet exist, and if that is the case would you mind if I took at shot at implementing it?

[nikolassv]

Thanks for offering to help. This feature is indeed not yet implemented, and I'd welcome a PR if you'd like to work on it. Feel free to ask if you have any questions as you proceed.

It would be important for this feature to be backward compatible. This means old Bartib logs should work with new software versions, and old software versions should work with Bartib files created by newer versions

Regarding the implementation, I would suggest adding tags to activity descriptions in the form of hashtags, like in this example:

bartib start -p "My super important project" -m "Chat with co-workers #nonbillable"

In this case, the entry would contain the #nonbillable tag.

Do you think this approach is feasible?

[DeliciousHair]

Thanks for the interest!

Yes, that approach could definitely work. However, it also feels like it could be a bit of a hack in the sense that it keeps the backwards compatibility while possibly painting yourself into a bit of a corner for future extensions / revisions, let alone the problem that users may already be using the # character already. For example, something like

bartib start -p "XYZ-123" -d "meeting with clients to discuss issue #827"

or even more (potentially) troublesome

bartib start -p "XYZ-123" -d "meeting to discuss issue #827 with clients #billable"

This can descend into something brittle quite quickly.

To be honest, I had not actually thought about backwards compatibility before now. It's a really important point though, and I'll need to have a think about it for a minute.

[DeliciousHair]

@nikolassv would you be open to considering the use of JSON for the log file? This could be done in a 100% backward-compatible manner, and would also make future additions/changes quite simple too.

For example, the current format is:

<start time> - <end time> | <project> | <description>

which could stay nice and human-readable and easy to not make a mess of--I saw your comment somewhere else in here about CSV data and agree with it FWIW--by using something like:

[
  {
    "start-time": YYYY-mm-dd HH:MM,
    "end-time": Option<YYYY-mm-dd HH:MM>,
    "project": "ABC-123",
    "description": "can use #hastags in the text without fear, like current",
    "tag": "new and exciting",
    "another_future_field": "..."
  },
  { ... }
]

It's not the most ideal of data-structures in an absolute sense, but I think it ticks the boxes that you're after in terms of a balance of functionality and human-readability.

Going one step further, It also has the added feature that JSON makes it possible to rather trivially farm all the parsing/aggregation/reporting out to polars in order to simplify/expand that side of things as well.

[nikolassv]

Thanks for sharing your thoughts on the data format and the tag suggestion!

The current plaintext format is a core design principle for Bartib, and I intend to keep it that way. The main reasons for this decision are:

• Human-Readability & Simplicity: I prioritize a format that's as close to pure plaintext as possible, making it easy to read and work with manually.
• Flexibility: It offers a high degree of flexibility for various use cases.
• Feature Creep Guardrail: The plaintext format also serves as a guard against feature creep. My philosophy is that if a feature cannot be implemented cleanly within the constraints of the current plaintext format, it likely shouldn't be added to Bartib.

Therefore, changing the underlying data format to JSON or anything else isn't something I am planning to do.

Concerning hashtags as Tags: I understand your concern about potential interpretation issues with hashtags, but I believe the example you provided, meeting to discuss issue #827 with clients #billable, doesn't pose a significant problem.

In our proposed approach, #827 would only be interpreted as a tag if we explicitly use it for filtering. For instance, if a user runs bartib list --tag billable, only the #billable tag would be considered for filtering.

While a command to list all available tags might occasionally display "superfluous" entries like #827, I don't see this as a major issue that would hinder the functionality or usability. The primary goal is to use these for specific filtering operations.

[DeliciousHair]

While I cannot say I 100% agree with the thinking, I do very much see your point and also appreciate you clearing up how you envision the hashtags approach working.

To be clear, I initially understood your proposal to be that they would be used as a single trailing item in the description filed, but it seems that you're actually saying they can be used anywhere in the description field, with multiple hashtags (my problematic example) actually being fine in that a single item can have several tags? Or, for backwards compatibility, none at all?

If I'm understanding this correctly, then I should be able to jump into making it happen.

[nikolassv]

Sorry for letting you wait so long! Yes, I think it should be possible that an item has an unlimited number of tags. So it may be none, one or even many tags for each item.

[DeliciousHair]

Apologies for dropping off for so long, work and all. I have picked this up again and run into a problem of the "how should this work?" variety.

Assume a line entry:

2025-08-21 20:00 - 2025-08-21 21:00 | Tags in bartib | Open source #programming in #rust

Using the same b-tree approach employed for grouping by description with a little bit of regex enables report generation with grouping by tag, but since a line can have an arbitrary number of tags per line this means that time will be counted more than once. For example, the above entry would report 1h for #programming and 1h for #rust, which is obviously not terribly useful.

How would you like to resolve this?

[nikolassv]

That's a great question, thanks for thinking it through. My gut feeling is that it should be fine for an activity to appear more than once if it has multiple tags.

Think of it like a resume: if I worked as a developer for five years, with two years using Java and Rust, and three years using Java and Scala, my experience would be listed as two years with Rust, three years with Scala, and five years with Java. Even though my total professional experience is only five years, I would still account for each skill individually.

In the same way, an activity's total duration remains the same, but it can be counted under different tags to give a more detailed view of the work performed.

[DeliciousHair]

Thanks, that works and I should be able to put it together quickly! Although likely not as soon as I would want.

[bjornasm]

Hey, are there any progress here? I think tags would be a great addition to Bartib. My use case for tags is to simply mark if I have registered the tracked hours in my works time registering system, while I could export the data and handle that elsewhere it would be nice to be able to just add a simple tag to it to indicate that it was registered.