zk list --created date, returns notes from one day after if YAML date does not have timestamp

[tjex]

zk list --created date, returns notes from one day after if YAML date does not have timestamp

[tjex]

Well... Its strange. If I replicate the steps in my testing vault, it works as expected. Will need to investigate (much) further.

[tjex]

Getting this on zk new

zk: warning: sql: Scan error on column index 2, name "source_path": converting NULL to string is unsupported

But again, not in the test vault, so this will be something in my config I'm guessing

[tjex]

Deleted and regenerated my notebook.md. This fixed the error message. But whenever I create a new note, and print out the data on it, it states it was created 17 hours ago (the same as in the original case of my daily note)

[tjex]

If I copy the file from my own vault, to the testing vault, and run zk index, the file that was created today also reports that it was created (now) 17 hours ago.

This is despite the 'bug' not being present in the testing vault whereby I can create a note with zk new and it will show up in zk list --created=2024-01-17.

If I run the same process in my own vault, the note will not be returned under notes created on 2024-01-17.

This is super weird...

[tjex]

So, I've narrowed it down to my custom default template.

For some reason this template:

---
title: {{title}}
date: {{format-date now}}
id: {{id}}
tags: [seed]
aliases:
---

# {{title}}

{{content}}


---
References:

Is creating a 'created date' as seen by zk at a fixed time (as the time elapsed is always increasing) , currently notes being created are given the elapsed time of '18 hours ago'.

The standard default template does not produce this error.
I can create a note and it will report being created 'just now' when queried.

[tjex]

It was the {{format-date now}} being included in the frontmatter.

A note created with this template, will return the correct creation date.

---
title: {{title}}
id: {{id}}
tags: [seed]
aliases:
---

# {{title}}

{{content}}


---
References:

Will look into this further

[mickael-menu]

That's right, the note creation date is taken from, in order of precedence:

1. date in the YAML frontmatter
2. file creation date on the file system
3. the current time as a fallback

I thought it made sense to use the date from the YAML frontmatter, but this is arguable.

Maybe there's an issue in the parsing or output of the {{format-date now}}?

[tjex]

Yes it could be that, or a design flaw in the time library the time elapsed library we use (forgot the name).

Date today = 2024-01-18

zk list --created=2024-01-16
2024-01-17 d/2024/2024-01-17.md (yesterday)

So --created=2024-01-16 looks like it means "all notes from 2024-01-16 00:00 till 2024-01-17 00:00". But this is confusing as I would expect to be shown notes from 2024-01-16 00:00 till 2024-01-17 23:59` when asking for ntoes created on 2024-01-16

So it's working like this:

• creating a note without a time stamp will show the note when querying the previous day.
• creating a note with a timestamp will show the note when querying that same day.

[tjex]

It would appear like the date in YAML isn't being respected at all.

I manually created a note now at 22:37, and gave it the date as if it were made 1 minute past midnight today. Then ran zk index

sys > ./zk list --created=today
2024-01-18 00:00:00 +0100 CET <- fmt.Println(start of day value)
delete delete.md (1 minute ago)

---
date: 2024-01-18 00:01
---

# delete

If I create a note via zk new, it clearly takes the YAML date, but that also shows that something weird is going on as despite having created the note, I get the elapsed time of 'not yet)

I've run the cmd again 10 minutes later at 22:45, and it's still returning 'not yet'

sys > ./zk list --created=today
2024-01-18 00:00:00 +0100 CET
delete 0mr2.md (not yet)

  ‣ # delete

---
title: delete
date: 2024-01-18 22:35
id: 0mr2
tags: [seed]
aliases: []
---

# delete

This is making me think that something is up on the sql or YAML side. As when zk is reading the date from a notes system metadata, instead of YAML, it behaves as expected.

[tjex]

closed with #384