Sorry if there is already a solution for this. I couldn’t find it.
Currently, sorting by Created time only works for as long as you never move notes to another filesystem or have to restore from a backup. Any user who implements a note taking system that relies on this type of sorting will be in trouble eventually.
This is because there is no practical way to restore filesystem-level creation times (which Obsidian seems to use) on copy/restore. Or it may be possible on some filesystems, but not on others, like ext4.
In other words, a note’s logical creation date is not generally equivalent to the creation date of the file that contains the note, so you could argue that sorting option provided by the app cannot work correctly based on just the filesystem metadata.
Proposed solution
When determining a note’s creation timestamp for sorting purposes, prefer a dedicated metadata field in the front matter, if present, and fall back to the filesystem metadata otherwise.
This way we could at least write a script to update the front matter before running a backup or a migration.
You can partially achieve this, the part about saving the timestamp in the YAML, using Templater which is available in the Community Plugins. With it you can set a default template for new files and add the date/time in there. For example, this is what my default template looks like,
Unfortunately no, not yet. Hence, the partial solution. It might still be useful to do this so that if Obsidian implements it (or some plug-in does), our notes would have the data already to work with.
Keep the notes directory in a dedicated partition, which is backed up by taking filesystem snapshots.
Making and restoring such a backup is more complicated, but it should theoretically preserve all metadata and there will be no need to bother with front matter timestamps.
Curious as to the need for a separate partition for text files! After my last post, I went and checked some of my old notes and I couldn’t find any notes changing their creation times accidentally. I do support the FR for more options for creation metadata but I think you might be encountering a bug perhaps.
The point of a partition is to be able to restore it without modifying file metadata.
I don’t know what filesystem you use, but in Linux (ext4) you can break the creation date by simply moving a file to another drive and back with no way to recover the original date.
Interesting. I am on a Mac and didn’t know that. I just read about it and turns out Windows (and Linux from your experience) treat time as file-system centric so whenever a file enters the file-system, it gets that time whereas Macs treat time as document-centric so it is preserved when you move files around.
Yes, this is the problem. In particular when moving between partitions / filesystems. When moving within a single partition, the dates are actually preserved.
I am not speaking of setting the creation time. The command is to copy file(s) while preserving their existing creation time.
-p same as --preserve=mode,ownership,timestamps
--preserve[=ATTR_LIST]
preserve the specified attributes (default:
mode,ownership,timestamps), if possible additional
attributes: context, links, xattr, all
Hi, just wanted to point out that there is another use case which pretty much requires the use of a creation date in frontmatter, namely importing notes from other systems.
It would be really great if Obsidian supported the use of a standard created frontmatter variable.
I’m also looking for that feature. Trying to fix the creation time on MacOS of files is PITA. Frontmatter would make that field super accessible. I used to fix creation time of journal entries so that they sort properly all the time in Evernote (which made that field user-editable.)