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:
FROM "Periodic Notes/Daily Notes"
SORT file.day DESC
Here are the two images which illustrate the problem.
![Files As Listed by Operating System|690x328](upload://v4dbiMrTF4KA1kRXxZlzzWXp6td.png)
Here is the Templater code I used as a test for the date:
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.
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.
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 to include .toString(), so that the table doesn’t show just “<date>”.