Block Timestamps

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.

1 Like

Also see this.

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.

Why bullet-level timestamps are useful

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


  • Every block aka bullet, should track two timestamps: creation and “last updated”
    • This means each individual bullet, subbullet, subsubbullet, etc. gets its own timestamp
  • Pages should have their own timestamp set as well


  1. Created time should never change after the very first creation, even upon refresh/re-index, etc.
  2. Updated time should only be updated upon true block updates, and be written to disk immediately
  3. When a block is dragged and moved up/down, it should retain its original creation date. Updated time should change with a block move
  4. When a block is cut and pasted, it should retain its original creation date


  • Human readable time for create/update should be visible on each block’s right-click menu.


  • Ideally, these timestamps would be considered as block metadata, and stored within the .md file
  • if that is too much clutter, timestamps could be stored in a block-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 recent bug. It is not within the scope of the bug to address most of the above.

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:

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.