Template inputs Date/Time tags in incorrect format

What I’m trying to do

When daily notes are automatically created each day on startup, or when clicking ‘open today’s daily note’, the time and date fields don’t input in the format that I have them set to in my template settings.

Things I have tried

I’ve tried inserting the templates manually, which fixes the date issue. However the hours are missing from the time template (I assume this is because it thinks it is just a number due to my format, therefore it doesn’t see a problem with removing the 00 at the start of it, which is a separate issue but not one I come across enough to have a problem with)

20240109003559

It’s not a huge pain, but is there a way to solve this? It would be nice to not have to reinsert the template every time I open the note.

Huh. When the time rolls over to 01:00, what are you seeing input then?

I know there are a few fields to fill in for Templates and Daily Notes, but can you try it in the Sandbox vault?

When these settings:

Clicking on the ribbon’s Open today’s daily note icon, using Open daily note on startup, and running the Daily notes: Open today’s daily note command all seem alright here. I created and deleted the daily note a few times trying the different scenarios.

To me it looks like your’re having the same problem in your screenshots though?

I wasn’t clear enough in the initial post, but I’m specifically talking about the hypen being put in place between YYYYMMDD with regards to the date, and the colon being put in between the minutes / hours on time.

When I input the template manually, it doesn’t add the hypen/colon in these locations but does when automatically generated.

I parse my notes a lot with things outside of obsidian so the added punctuation causes some pain there with some of the tools I use rather than just having the number, especially if notes are inconsistent where some have this and some dont.

Can you do "{{date}}" and do that give you what you want?

I think part of the issue is that dates are often stored in ISO 8601 within Obsidian to make them compliant with other bits and pieces. And if this is the case, then the the is used for display purposes. But I might be wrong on this account.

Understood. Yes, I see the same behavior. I was only looking at the time itself and not the hyphens or colons.

Yeah, if I manually run the template (in any note):

If it’s run through the ribbon’s Open today’s daily note icon, or running the Daily notes: Open today’s daily note command:

Unfortunately, holroy’s suggestion gives me this (using the Open today’s daily note icon):

Are you able to do: {{date:YYYYMMDD}} and {{time:HHmm}}?

This doesn’t use the settings format, but sets the format directly where you use it.

2 Likes

Nice! That works for the Open today’s daily note ribbon icon.

CleanShot 2024-01-10 at 08.45.51


So, it seems when Daily Notes is run by whatever means, it doesn’t look at the settings set in Templates at all. Those are only for the Templates commands themselves. I feel I knew this at some point, but have used Periodic Notes with Templater for so long that I forgot.

Setting this:

Still results in:

---
tags:
  - daily
date: 2024-01-10
time: 08:53
---
1 Like

Interesting. It feels like this is a bug, and while the solution here works it is a bit of a workaround.

Is there a way to turn this into a bug report at all?

Actually, I believe using the non-standard date format is the workaround. By using that you are disqualifying the file.day of dataview, and multiple other plugins ability to query the date directly. Furthermore, when the properties keep that format when storing, but allows different viewing formats that’s a good extension.

As long as your custom dateformat stears away from localised date formats, you’re luckily still able to reparse your text string into a proper date within dataview queries. But it makes all date queries more complicated.

So it’s depending on your context to say what is the workaround and/or bug. I do see your argument on other software, but still in my book I believe conformity towards ISO 8601 is the better way to go.

Found this in the graveyard: