File Creation Date is incorrectly reported on openSUSE Tumbleweed

Steps to reproduce

Expected result

I expect to see the list of files with the correct date as reported by the operating system.

Actual result

I get a list which consists of the same date: 1969-12-31.

When using the Templater code, the creation date is as above. The modification date is correct.

Environment

SYSTEM INFO:
Obsidian version: v1.5.3
Installer version: v1.5.3
Operating system: #1 SMP PREEMPT_DYNAMIC Thu Jan 11 08:01:39 UTC 2024 (05ae4ad) 6.6.11-1-default
Login status: not logged in
Insider build toggle: off
Live preview: on
Base theme: dark
Community theme: none
Snippets enabled: 0
Restricted mode: off
Plugins installed: 19
Plugins enabled: 19
1: Excalidraw v2.0.16
2: Kanban v1.5.3
3: JSON/CSV Importer v0.33.0
4: Multi-Column Markdown v0.8.3
5: Text Format v2.2.8
6: Trash Explorer v1.2.2
7: Imgur Plugin v2.4.0
8: Paste URL into selection v1.7.0
9: Templater v1.18.3
10: Full Calendar v0.10.7
11: QuickAdd v1.6.1
12: Better File Link v1.1.4
13: Image Toolkit v1.4.1
14: Advanced Tables v0.19.1
15: Outliner v4.8.0
16: Homepage v3.6.0
17: Excel to Markdown Table v0.4.0
18: Periodic Notes v0.0.17
19: Dataview v0.5.64


I don’t know what the hell happened above, but all my steps to reproduce and the two images of the results I upload have disappeared.

Here is the Dataview query that produces these results:

```dataview
LIST dateformat(file.cday,"yyyy-MM-dd")
FROM "Periodic Notes/Daily Notes"
SORT file.day DESC
LIMIT 100

Here are the two images which illustrate the problem.

![Files As Listed by Operating System|690x328](upload://v4dbiMrTF4KA1kRXxZlzzWXp6td.png)

![Obsidian List|690x468](upload://ny47K79t53mbcE7SkehSkFYQ8CC.png)

Here is the Templater code I used as a test for the date:

creation date: <% tp.file.creation_date() %>
modification date: <% tp.file.last_modified_date(“dddd Do MMMM YYYY HH:mm:ss”)%>

Here is the result I get from that code:

---
creation date: 1969-12-31 16:00
modification date: Thursday 18th January 2024 01:56:43
---

As you can see, the creation date is wrong, but the modification date is correct.

Again, I am running on openSUSE Tumbleweed latest snapshot with the KDE desktop.

I don’t know why my uploaded images aren’t showing…they showed in the side panel when I uploaded them. This is a truly crappy bug reporting system.

The problem once again is that both Dataview and Templater return the same incorrect day for the cday variable or the Templater tp.file.creation_date().

Moved to help.

Bug reports aren’t considered using community plugins.

Yeah, great. And frankly I expect zero help.

There are some Dataview and Templater pros here and on Discord always willing to help.

I’d try to reproduce your issue again and give step by step instructions. Hopefully someone can chime in.

Thanks, I appreciate it. The thing is I’m trying to set up a system to review previous notes so I need this capability to select files with an accurate date. If the date function is hosed, that shoots that whole project down.

I’ve seen mentioned many times that mtime is unreliable, and that ctime may not always be accurate depending on your OS and if you sync your files across devices and different OSes.

Is the ctime which is most unreliable, since that can be reset on sync, backup/restore, and a few others. He tried showing his result in these images:


Could you try this query, and report back what it says. Be sure to not paste the images in a code block :slight_smile:

```dataview
TABLE file.day, file.cday, file.ctime, file.mday, file.mtime, typeof(file.cday)
FROM "Periodic Notes/Daily Notes"
SORT file.day DESC
LIMIT 10
```

I’ve not seen this behavior before, so it would be nice to see the result of this query, and if possible also the frontmatter of one of the files from that result table.

That query does absolutely nothing. It does not appear to even execute.

What is the SQL prefix supposed to do? If I remove that, the query does execute.

Huh? No error message, or no output? That’s really strange. Have you tried restarting Obsidian (and/or your computer)? This is not normal behavior

As you see removing the SQL prefix allowed the query to execute. As for frontmatter in those Daily Notes, there is none. I haven’t started using front matter or properties yet.

By the way, the incorrect date being displayed is the UNIX “epoch date”. This indicates a major bug somewhere.

Hmmm… which SQL prefix? But that it mayters I got to see the wrongful report of the ctime/cdate. But I need a minute to build the next test script to determine if dataview is buggy, or where the issue is.

By some reasoning your query returns a zero value for ctime/cday, which produces that date when localised.

Returning a zero date which causes it to default to the UNIX epoch date makes sense.

The SQL prefix I referred to is from your post above - which now seems to have mysteriously disappeared from your post! There was four tick marks and the word SQL before the Dataview query and another 4 tick marks after the end of the Dataview query three tick marks. Now I can’t see them in your post. No idea what’s going on there but there it got copied over when I copied and pasted your query into Obsidian.

The 4 backticks were just there in Holroy’s post to format the dataview query as a code block (so it would be more readable :blush: )

This is just how you can display, here, on the forum, a full dataview/dataviewjs query: by using nested code-blocks such as the one below :blush: .

````
```dataview
dataview query here
```
````

When pasted, you’re supposed to remove the outer block code (if it came through) :blush:

I suspect the problem may be that modern UNIX file systems like ext4 and btrfs use different fields than the old ctime. Ext4 uses crtime and btrfs used otime.

I suspect that this distinction is not being recognized by either Obsidian or perhaps some of the libraries people are using for their plugins.

See this article on the subject:
Get File Creation Date/Time in Bash

OK, I should have noticed that since I’ve seen the four ticks for code blocks.

1 Like

It could be, but please adapt and try the following query:

```dataviewjs

const result = await dv.pages('"Periodic Notes/Daily Notes"')
  .where(p => p.file.name.startsWith("2024-01"))
  .map(p => [p.file.name, p.file.cday, p.file, 0])

let counter = 0
result.values.forEach(r => {
  console.log(r[2].path)
  const fs = app.vault.adapter.fs
  const fullPath = app.vault.adapter.basePath + "/" + r[2].path
  console.log(fullPath)
  
  //const file_fd = app.vault.adapater.fs.openSync(r[2].path)
  const fstats = app.vault.adapter.fs.statSync(fullPath)
  r[2] = fstats.ctimeMs
  r[3] = fstats.ctime.toString()
  counter += 1
})

dv.table(["file.name", "file.cday", "ctimeMs", "ctime"], result.values)
```

This script bypasses dataview to get the actual dates as reported by the operating system. If the last two columns still show the incorrect values, it’s something happening before Obsidian gets to see the dates. Possibly your system using the “crtimes” stuff you just mentioned.

Update: Corrected the output for r[3] to include .toString(), so that the table doesn’t show just “<date>”.

Here you go: