Currently obsidian uses the filesystem information to determine file creation date and file modification date.
This is brittle because not all filesystems support this feature and these dates can become meaningless during file transfer operations.
It would be better to handle those internally and directly by Obsidian.
Related:
Soā¦as long as I stay in the Apple ecosystem (Internal or external HD Folder/iCloud/CloudKit) then I do NOT have to worry about Obsidian Sync changing the Creation Date (between iDevices)as described by the OP in the thread you reference?
Hi, Iām wondering how to access the creation date / modification date of a file from inside Obsidian. Is that at all possible?
This is a needed feature for me - on Linux, this makes the created and modified dates far too brittle
This is a problem for me as well.
Syncing between 2 Window laptops, 1 LX laptop and 2 Android devices messes upp the filesystem creation date beyond belief.
To indicate creation and modification dates in my vault I use this code in a āfile headerā template
Created Date: `$= dv.el('span', dv.current().file.ctime.toLocaleString(DateTime.DATETIME_MED_WITH_SECONDS))`
Modified: `$= dv.el('span', dv.current().file.mtime.toLocaleString(DateTime.DATETIME_MED_WITH_SECONDS))`
But as soon as it syncs to say, Android, the creation date is set to NOW()
So I started using
Created: {{date:YYMMDD}}-{{time:HH:mm:ss}}
for every new file that I create, so that it stays the same (and correct) throughout all syncs
Iām also using this as a āinsert current dateā template to manually indicate modified date.
Klunky, but works independently from FS dates.
Found this thread from searching for Tp.file.creation_date showing 1970? trying to figure out why tp.file.creation_date() keeps giving date as 1970 (specifically 1970-01-01 10:00).
This was because the file in linux was being written where the creation date is unknown.
So Iāve opted for tp.date.now() like in my current daily note template shown below
---
creation date: <%tp.date.now()%>
tags: DailyNote, <%tp.date.now("YYYY")%>, <%tp.date.now("YYYY-MMM")%>, <%tp.date.now("GGGG-[W]WW")%>, <%tp.date.now("YYYY-MM-DD")%>, <%tp.date.now("YYYY-MMM-DD")%>
alias: <%tp.date.now("dddd Do MMMM YYYY")%>
---
# <% tp.file.title %> - {{date:dddd, Do MMMM YYYY}}
[ISO Date](https://en.wikipedia.org/wiki/ISO_8601): {{date:YYYY-MM-DD}}
[ISO Week Date](https://en.wikipedia.org/wiki/ISO_week_date): {{date:GGGG-[W]WW-E}}
So hopefully this is a good alternative approach to the above.
@witecat you can use my plugin to update the modified date when the file is edited in Obsidian, rather than the file modified time:
Itās pending submission to the plugin store, but you can use BRAT to install it.
I think this can be tagged with āpropertiesā now that they are becoming a thing. I donāt see any other way of implementing this in a portable manner.
And yeah, I sorely want this feature to become a thing. I finally decided to play around with git plugin the other dayā¦ And was reminded that git doesnāt preserve metadata 
Thankfully I made a backup beforehand, but losing all my cdate and mdate was terrifying.
Filesystem creation times (FCTs) are very fickle, and by extension, Obsidianās features and community plug-ins which rely on it: Sorting by created time, calendars by created time, automated note trackers, graph view timelapses, and even Obsidian Sync is affected from what Iāve read. You have to be very careful with the original markdown files to ensure its creation timestamps remain untouched, else you risk ruining features which rely on these. There have already been a good few recorded cases of improper handling of files which led to wiped creation timestamps, and with each one came a justifiably frustrated user. āUse cut and paste next timeā, they saidā¦ but that wonāt bring back what was already lost, nor can it fully prevent another occurrence.
Thereās just really no simple way of preserving creation dates without resorting to some niche system command or obscure third party program, and that can drive away the average user in the long-term should they plan to switch platforms or devices. And there are even operating systems that donāt bother with creation dates at all (Linux and Android), so it wonāt become apparent to users on those platforms as to whether or not their creation times got wiped until they open Obsidian.
I propose a native YAML front matter key that overrides creation time throughout Obsidian, as well as {{cdate}} and {{ctime}} template inserts that follow a fixed time format. This would save Obsidian from relying only on FCTs for features and functions that revolve around a fileās creation time.
Refer to this for time formats.
---
#creation: (date value) (time value)
creation: YYYYMMDD HHmmssSSS
creation: {{cdate}} {{ctime}}
---
This would definitely be helpful. Here are two more relevant threads: Wrong Date Created Property and Preserve Creation Dates when Using Obsidian Sync
Thanks!
Iām now unable to edit the original post, but I found another related feature request which is more or less the same idea, but this discussion has a workaround involving partitions and the use of ddrescue on Linux. This also touches upon cp -p which Iāve tested myself, though sadly it doesnāt preserve creation times, only modification times.
Right now, Iām using Templater instead of Templates to fulfill the {{cdate}} and {{ctime}} inserts, and would like to add to the āā¦fixed time formatā, with āwhile allowing users to specify one-off custom formats as seen on the {{date}} and {{time}} inserts.ā
Need for this implementation mentioned here:
Thanks Alan, will give it a try.
Now that the properties feature has arrived and can serve as the basis for robust created and modified date metadata, are there plans to implement this metadata as properties?
I was about to make a thread and argue properly for why file metadata is wholly inadequate for note metadata but Iām glad this has already been argued plenty here.
In short: filesystem metadata pertains to files and the filesystem, not the content of a file or note and is designed for file operations and OS internal use. It is not tied to the content of a note and using it as note metadata is like assuming the print date of a book is when it was written.
As a user it is tremendously important to me though to have a creation and modified date associated with my notes. Oftentimes, this is the most important information needed to put a note into context. Not having a reliable, integrated handling of this in Obsidian has been the single reason I havenāt switched to Obsidian as my main notetaking app. I would therefore greatly appreciate a native implementation of note dates as properties.
Iāve been following this issue for a long time now, and this is the best summation of the problem that I have seen.
@Illiou ā while I still think this should be core functionality, the workaround I have recently found is working well. It involves two plugins:
The Linter plugin can insert YAML properties, including Date Created and Date Modified. I have Date Created enabled. Thereās also a setting āForce Date Created Key Value Retentionā which keeps filesystem metadata changes from altering the original Date Created. Linter be set to act on a key combination, or on a variety of file operations. I have it set to Lint on Save and Lint on File Change, so itās set-and-forget.
The plugin Update Frontmatter Modified Date āā¦is different from other plugins in that it does not use the filesystem modified time. The frontmatter will only update when you actually work on a file inside Obsidian.ā
The combination of these two plugins is providing me with reliable Date Created and Date Modified in frontmatter that are not subject to mangling by the filesystem.
Just found out that my posts about this issue were moved to a unified thread. Iāve learned a lot more in the time since then, so I figured that I should share it here.
I donāt really have a problem with modification times, but with how easily these change, it wouldnāt be so wise to record or work solely based on these. Letās put it this way: You opened a note, and for some reason, you were in edit mode. You then pressed on your spacebar thinking that it would scroll down, but instead, some whitespace was typed. Given the nature of Obsidian, all edits are immediately saved without having to do Ctrl/Cmd+S, so the modified time ends up changed, regardless of whether or not it was intentional. This happens a lot to me.
What I propose could be done instead is adding a ānewest/oldest editedā sort filter that keeps track of which files were last edited using Obsidian via some .json list in the vaultās .obsidian folder, or in the Roaming or Application Support folder for tracking across vaults. On top of that, it may be best to let users redefine the conditions for a file to be considered edited (e.g. at least 10 characters must be altered to be considered). This would, however, require that there be unique identifiers for each note, which will have to be made in-house as file UIDs across different platforms are another can of worms (see Windows/NTFS handles and Linux inodes, MacOS/APFS doesnāt have file UIDs).
I still abide by my first proposal in being able to store these in the frontmatter, and now the note properties as a manual override to the file system metadata. However, Obsidian could probably benefit from having a .json record of these for platforms with limited to no support of storing or altering file creation times (especially Linux and Android). Again, such .json records would require unique identifiers for each note (see above), but it would be an effective, automatic, and unobtrusive means of note timekeeping; a solution much more preferrable than forcing users to actively record these as part of their workflow.
For those looking to preserve their creation timestamps right now, itās quite simple really:
Keep a record of creation times in UNIX millisecond timestamps, and store those somewhere safe but accessible. You can easily do this with Templater or even the Templates core plugin. I have mine suffixed in the file name so that I can easily restore these using a script.
In backing up your vault, use a file archiver thatās able to store creation times. I use 7-zip which can do so with nanosecond precision. Not doing so will cause the archived files to have their creation timestamps lost, and upon extraction, will be replaced with its ātime of first existenceā on the file system. As of 7-zip 21.07, files on Linux can be stored with 1 ns precision.
This is my most definitive take on the matter to date, and maybe the last one Iāll do. Hopefully the team or any of the readers get something out of this. (:
