Handle file creation date / modified date internally (don't use the filesystem info)

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:

11 Likes

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?

1 Like

This is a needed feature for me - on Linux, this makes the created and modified dates far too brittle

2 Likes

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.

2 Likes

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 :wink: Thankfully I made a backup beforehand, but losing all my cdate and mdate was terrifying.

Use case or problem

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.

image

Proposed solution

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}}
---

Related feature requests

7 Likes

This would definitely be helpful. Here are two more relevant threads: Wrong Date Created Property and Preserve Creation Dates when Using Obsidian Sync

Thanks!

2 Likes

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.ā€