#1

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

220213-
The same time stamp as the first one at start.

Actual result

220214-
Time is incremented

Environment

  • 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.

#2

This is not a bug.

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

#3

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

#4

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.

#5

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.

#6

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.

#7

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

Angel

#8

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.

#9