Struggling with YAML frontmatter date attribute and date comparison query in Silverbullet

Hi everyone,

I’m currently facing an issue with Silverbullet regarding the YAML formatter date attribute and implementing a query based on date comparison.

Here’s what I’m working with:

I have template-based notes that include two YAML formatter attributes: date and tags. The date value is inserted using {{today}} when the page is created, resulting in YAML metadata like e.g. this:

---
date: 2024-05-01
tags: inbox-note
---

The Problem:

Despite setting the date correctly, my queries are not working as expected. For example:

Query for exact date match:

inbox-note where date = 2024-05-01 render [[Library/Core/Query/Page]]

Query for date comparison (greater than or equal to):

inbox-note where date >= 2024-01-01 render [[Library/Core/Query/Page]]

Neither of these queries returns the expected results.

Questions:

  • Is there a specific format or syntax required for date queries in Silverbullet that I’m missing?
  • Are there any known issues or limitations with date comparisons in Silverbullet queries?

Furthermore I can see when querying

inbox-note

Pages all pages are listed but the value for the date column is empty, even though page contains

---
date: 2024-05-01
tags: inbox-note
---

Any hints, tips, or guidance would be greatly appreciated.

Thanks in advance!

Cheers,
Tim

2 Likes

I think the expectation here is that date will be quoted as in the frontmatter would be formatted like date: "2024-05-01". I’m guessing that when it is not quoted, it kinda treats it like a numbers and errors out trying to parse it.

1 Like

Thank you for your comment, meain! I have already tried that. In this case, it is treated as a string, and only the equals comparison works, but not the “>=” or “<=” comparison.

A workaround would be using numbers like: date = 20240501. However, I want to use {{today}} in my templates, which produces 2024-05-01. I still hope I’m missing something in the query to handle dates properly or that I need to format the {{today}} variable differently in the frontmatter section.

Huh, odd. I am able to have the following query in my space which does do the filtering. I’m not 0.7.6 in case that is the difference.

{{#each @pg in {page where name =~ /^Folder\// and date <= tomorrow order by date desc limit 10}}}
[[{{@pg.name}}]] on {{@pg.date}}
{{/each}}

Thank you for the tip. I still can’t get it to work on my end. Where does this date attribute in your query come from? Is it part of your the frontmatter declaration, like

date: 2024-05-01

or does this date refer to the implicit createdDate of the page?

Part of the frontmatter.

---
date: "2024-05-16"
other: Tag
---

Btw, you might also want to quote the date in the query, ie something like:

inbox-note where date >= "2024-01-01" render [[Library/Core/Query/Page]]

I got it now. You had already provided the answer in your first reply. Both in the frontmatter declaration and in the query, the date must be formatted as a string in quotes like “2024-05-01”.

I mistakenly thought I had tested this unsuccessfully… but I got confused during validation because in my test notes the createdDate was in the name, and the date in the frontmatter was different…

Long story short: Thank you very much.

2 Likes

What’s a bit tricky is that we have two languages here:

  • YAML: where the 2025-06-01 notation is interpreted as a date, not as a string. So to get the string interpretation, you need to add quotes
  • The SilverBullet query and expression language (Expression Language) where 2025-06-01 actually means “take 2025, substract 6, then substract 1” which is probably not what you would expect.

In both cases explicitly using quotes should fix this, but it can be hard to catch. The various operators (=, !=, <=) should work with strings too, so that’s probably the safe way to go.

2 Likes

@zef do you think it would be possible to post-process the YAML date? e.g. call toString() on it inside the query or to in general treat it as a string when silverbullet parses YAML.

I use Hugo for publishing and the workaround with quoting the date works so this is not a big issue, but it would be nice if it was possible to somehow normalise/post-process the YAML objects when querying them/

You can do this already in a query simply by appending it to a string "" + attibute or by creating a custom using space script that turns a date into whatever string format you like.

Thank you @zef I appreciate you taking the time to reply.

You sent me in a good direction and I think I found a bug in the YAML parsing, let me know if this looks like a bug and I can create a bug report on GitHub.

My pages have the date: 2024-07-06 attribute in their frontmatter.

When I used the ""+date as you suggested

```query
book select name, ""+date as da
```

I saw [object Object] in the output. Which is strange because ""+(new Date()) produces "Sat Jul 06 2024 14:30:45 GMT+0200 (Central European Summer Time)" in JavaScript

So I tried to write a space script to JSON.stringify() the date attribute:

```space-script
silverbullet.registerFunction({name: "inspectDate"}, (date) => {
  return JSON.stringify(date);
});
```
```query
book select name, inspectDate(date) as da
```

And I see {} everywhere in the output.

This leads me to believe that the YAML parser doesn’t parse the date attributes correctly (it parses the date into an empty object).

Does this make sense? Would you like me to do more investigation?

You’re right, putting in a date as 2024-06-23 indeed seems to result in an empty object, let me investigate…

Ok, yeah this was broken. I now turn dates into strings in post processing as of Parse YAML dates into strings · silverbulletmd/silverbullet@2eb7e25 · GitHub

If you’re Living on the edge (builds) then you can try this out by updating to the latest version in a few minutes, otherwise it will be part of the next release.

2 Likes

@zef Thank you so much! It works on the edge :tada: I created a small follow-up PR Follow-up for parsing YAML dates by viktomas · Pull Request #921 · silverbulletmd/silverbullet · GitHub

1 Like