Provide a setting to record the block created-at timestamp in the metadata of the block, and to store it in the respective Markdown or Org files.
This achieves an important feature parity with a number of tools like Roam Research, plain-text note-taking systems (Zettelkasten, etc), and other text and wiki tools (Drafts, etc).
Hi, and welcome to the forum.
I can’t be sure right now, but I believe that feature was present in previous versions and then removed.
However, there’s this line in config.edn: :feature/enable-block-timestamps? false
So, maybe changing that to true will bring block timestamps back for you.
Please! bring back Block Timestamps. There is a already a setting in the config file but it seems to have no impact:
:feature/enable-block-timestamps? true
This would allow organizing notes in a way other than through Journals.
It doesn’t do anything to old blocks. Just the new ones.
Although Logseq technically contains block level timestamps via :feature/enable-block-timestamps? in config.edn, the featureset is limited, unpredictable, and sometimes buggy. This makes it hard to use. Below is a comprehensive feature request around block level timestamps.
They provide useful context. Knowing when a bullet was written shows us the context under which an idea evolved or knowledge was gained, how outdated up to date it is, and so forth. This is a vital part of PKM
.md fileblock-timestamps.edn file. However, such storage should be ordered predictably, so that a visual inspection of the .edn file via a tool like git diff clearly shows the diffs as expected (current .edn storage seems to be a dictionary that is randomly ordered each time it is written, which is not desirable)Related feature request:
Thanks for posting this @micahredding & for @macedotavares for pointing to the config.edn.
I have enabled it and it works now. I also just realized that the time-format is UNIX time. So here is a convenient (and fast) epoch/time converter: https://www.epochconverter.com/
One slight nuisance is that the “created at” and “update” timestamp are (on my device) always the same, which means that it essentially only displays the time it was last updated.
(I have just checekd and this upadted time is not activated when the cursor is passing through, but it seemst to be activated once one starts typing - even if one erases it immediately).
This means that the timestamps are not as good for retrospective metadata for blocks one retroactively modifies.
I reached it using a workaround, actively tagging it in the block attribute, (because currently logoseq is almost missing sorting and retrieval capabilities, while datascript has powerful features,
Also, even if logoseq has the function of block timestamp, (you can only use datascript to sort and query, because logoseq has no other methods,),…
How did you “actively tag it in the block attributes”?
True, it would be great if it could be part of the (advanced) query, right?
How to bind items in block-timestamps.edn back to the markdown file?
Sounds inserting something like id:: for all blocks in the markdown is inevitable.
Yeah it doesn’t seem to work for me either. I don’t know how others are able to get it to work.
The ability to (optionally) see time stamps would be huge for me because it’s often something I want to see later (when did I do the thing that made me write this down?). That would be a lot nicer than always having to manually type /time and then see the timestamp even when I don’t want to see it (even worse: It would be stored non-semantically as a part of the text field).
The time could be displayed like the task time tracking - on the right side, as slightly de-empathized meta-info. When you hover over it, you could be shown the block’s edit history.
You can already see a page’s revision history inside of Logseq using the git integration, so I would think that this would be relatively easy and make a lot of sense to implement.
All the metadata (that is already there!) would be stored in the repository and wouldn’t pollute your files.
I agree… so wish this were available
The only issue is that you need some form of connection between the gut and the file because git cannot tell whcih block is whcih. What happens when you change the contents of a block? What happens if you delete a block?
Git doesn’t know something happened to a block just that x to x line changed. And the lines can change as you type more or less.
It’s not possible to get changes in blocks down to the level required by looking at file diffs, which is what git would offer, without being able to refer to each block individually
You’re right that it’s not perfect, but I’d argue it’s probably good enough for the use case. It’s good enough for almost every programmer to use almost every day, after all. A lot of things can be deduced from the context and I personally am mostly interested in when the block was created. Minor updates will be easily spotted by Git and if the content is completely different, it can be argued that a given block shouldn’t even be tied to its old identity.
Seems like Logseq is already aware of the create/update date for any block. I’m guessing this is only inside the Logseq database, and isn’t reflected in the Markdown file (which might not be a big deal). Is it just me or it looks like the heavy lifting has already been done? It would just be a matter of showing this metadata next to each block.
Using Dev mode in Logseq it is possible to look at each block’s metadata. As you can see, the block’s create/update timestamps are present:
This looks like the dev data for a page, have you checked for general blocks?
