"Creation date" Template Variable

Feature requests
1

Once you are done reading, please delete the above notes

Use case or problem

The core plugin Templates currently supports only three built-in variables: {{title}}, {{date}}, and {{time}}.

While these are helpful, they are too limited for users who want to include more metadata automatically in their notes.

For example, when creating templates for journals, meeting notes, or logs, it’s often necessary to include the file’s creation date to distinguish it from the edited or modified date.

Proposed solution

Add additional template variables to the core Templates plugin — specifically one for the creation date (e.g., {{creationdate}}).

This would make it possible to insert the original file creation timestamp directly into a note.

By doing so, users could standardize metadata across templates without relying on external plugins or manual scripting.

Current workaround (optional)

Currently, users have to manually enter the creation date or use community plugins like Templater that provide more flexible variable options.

However, this requires additional setup and maintenance, which goes against the simplicity and reliability of core plugins.

Related feature requests (optional)

There are several community discussions requesting expanded template variables or more metadata options in the core Templates plugin.

Adding {{creationdate}} would align with those needs and improve overall consistency across Obsidian’s templating features.

2 Likes
2

If you trigger the template when you create the note, or soon after, then {{date}} will be the creation date (or close enough that I wouldn’t expect the difference to matter). I would guess this is when most people would use a template that includes the creation date. Are you often creating a note but not using any templates in it until a later date?

Renamed thread to reflect the single variable it seems to be concerned with (was “Expand Template Variables in the Core “Templates” Plugin”).

1 Like
3

Yup, this is what I do. My “meta” template that I run on almost all new notes (that aren’t for something specific) is:

---
aliases: 
type:
status:
created: '{{date:YYYY-MM-DDTHH:mm}}'
tags:
---
# {{title}}
4

Thank you for sharing your setup — it’s a very clean and practical approach.

I completely understand that using {{date}} works fine when the template is triggered right after creating a new note.
However, for previously created notes, {{date}} simply inserts the current timestamp rather than the actual creation date of the file.
This becomes an issue when working with existing notes.

That’s why I suggested adding a dedicated {{creationdate}} variable — one that reflects the true file creation metadata even if the template is applied later.

More broadly, this request isn’t limited to just the creation date.
It would be great if the core Templates plugin supported a wider range of metadata variables — for example, {{modifieddate}}, {{filepath}}, {{vaultname}}, or others related to the note’s system attributes.
Expanding the built-in variable set would make the core plugin much more versatile without requiring users to rely on community plugins for basic metadata.

Thanks again for engaging with this discussion! I really appreciate the thoughtful responses.

5

@dosirak I would suggest you use the Templater plugin instead, which allows you to use all of the variables you have mentioned (and many many more).

You can do amazing things with Templater which you could never do with the core plugin, so it’s practically indispensable.

6

I’m all for expanding the core Templates variable options.

My only concern with {{creationdate}} and {{modifieddate}} is that they would pull from ctime and mtime which are unreliable when using multiple OSes and syncing (in my experience).

That said, Templater and/or Linter are very powerful, the basics easy to get working, and you can use them today.
7

Thanks for the reply — and yes, I’m already using Templater to achieve this functionality.

However, that’s actually the only reason I keep it enabled.

Managing both Templates (core) and Templater just for this single feature feels a bit cumbersome.

That’s why I thought it might be helpful if the core plugin supported it natively — not only for me, but probably for many other users who prefer to keep their setup lightweight.

I really appreciate you taking the time to discuss this!