Zettercasten bug with running Dates in format YYMMDD

Steps to reproduce

Create a Zettercasten file with the timestamp format YYMMDD-, ex 220213-

Add in the title to this string.

Create a new zettercasten document.

Expected result

The same time stamp as the first one at start.

Actual result

Time is incremented


  • Operating system:
  • Debug info:
    MacOSX 11.16.3
    Obsidian v0.13.23

Additional information

This bug has been around for a longer time, so it’s not a regression.

This is not a bug.

it helps users create new notes with a vault-wise unique time-based prefix .

It’s not expected result, if I want all zettelcasten to start with an ISO date, is should not change behind my back.

It is the expected result. You are misunderstanding what the ZK plugins is for.
The ZK plugins is for generating vault-wise unique time-based prefix, if there is already 220213-, than we must increment to 220214-, because 220213- already exists.

It does not exist, as I edit the 220213- to 220213-A title so it’s unique, next time I create a z-note it says 220214 without checking the directory that 22013- is still a valid file name. And then the time stamp is one day forward, two days forward, three days forward, four days forward and I need to go in an edit something that YYMMDD- should say is today’s date.

The prefix has to be unique, not just the title.

vault-wise unique prefix = the timestamp prefix has to be unique in the whole vault.

This is goal of this plugin not the bug. The last digit is incremented to guaranteed uniqueness.

This should help make things easier (does in my tests):


I usually just click on the space after - and add the file name. But yes, if the application has unfortunate side effects I need to go in and change the YYMMDD as well. Surprised when I saw it over and over – it looked like a trivial bug to fix by just checking if a file with the name is not present, most likely a one-line Javascript check.