Related recent bug. It is not within the scope of the bug to address most of the above.
Related feature request:
3 Likes
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,
But this approach can only be used in discussions on ongoing topics, or in longer blocks, (otherwise it would be too much of a waste of time,)
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,),…
1 Like
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.
4 Likes
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:
2 Likes
This looks like the dev data for a page, have you checked for general blocks?
I’m pretty confident this is the metadata for a block. I right click on different blocks, select “(Dev) Show block data” and I do get different things for different blocks.
Very strange, some blocks I see, some I don’t.
@jojorabbit, what you are seeing is just in the database. This is not persisted and a reindex or sync on another device would reset these dates.
4 Likes
@Aryan, do you know, how to interpret the :block/updated-at that jojorabbit showed? Does it even refer to a standard date and time or is it a timestamp relative to the last reindex or sync?
Question goes out to all, of course 
Edit: Seems like the whole feature of updated/created timestamps has been killed? At least, that is how I read this post here on Github: the built-in created-at property is changed as same as updated-at when block is edited · Issue #4994 · logseq/logseq · GitHub
There are certain contexts where timestamping can be a regulatory requirement. For example if you wanted to use Logseq as an electronic lab notebook in certain industries. The ability to integrate block time stamps with a trusted time-stamping solutions would be useful if technically complex.
See:
4 Likes