Preserve Creation Dates when Using Obsidian Sync

I previously posted about what I thought was a bug, in which a document created on day X on one machine, when synced with Obsidian Sync on a second machine on day X+Y, will display the X+Y creation date on the second machine, but retain the X creation date on the first machine. This poses problems with various Dataview queries (e.g. “on this day”-style queries), as the same query will express different results depending on which machine one is making the query on.

This issue doesn’t appear to affect syncing using, say, iCloud drive, and is specific to Obsidian Sync.

So, I propose that Obsidian Sync retain the original creation date of a document, when the document is recreated on new Obsidian instances after a sync request. (Same for the file’s modification date?)

24 Likes

I’m a little slow this morning, so are you saying that if I create a note with a Zettel Title of 20210928xxxx on my iPad Air, Obsidian has that, 20210928, as the creation date? Two weeks later I open my iPad Mini, Obsidian Sync does it’s thing, and I now have a note on the Mini with a Title of 20210928 and a creation date of 20211012, while the iPad Air still has the note with a creation date of 20210928?

Yes, that’s been my experience since switching over to Obsidian Sync from iCloud drive. I’ve had to re-write my Dataview scripts to look at the file name now, since the creation dates are meaningless depending on the device I’m on.

Well, I’d be interested in the Mods’ take on the issue

This is a much wider problem than Obsidian Sync. For example, if you were copy files into your Obsidian vault, the creation date for the new files will be set to the current time regardless of the creation date on the original file. Also, from what I understand, some file systems do not track a file’s creation date. So, if the creation date is an important piece of meta data for someone’s workflow, I suggest capturing it within the title of the note or the text of the note.

Personally, I think the solution is a setting or plugin that instructs Obsidian’s internal database to use metadata from the note itself instead of the file system creation date.

As a work around, I use a PowerShell script to reset the file’s creation date to match what is in my note. I run this periodically from the root of my vault.

# Get a listing of all the Markdown files within the current folder and all subfolders.
$files = Get-ChildItem "." -Recurse -Name -Filter "*.md"

foreach ($file in $files) {
	# The second line of every note is in this format: "created: YYYY-MM-DD HH:mmZZ".
	# So, extracting the date is done by reading the 2nd line and getting rid of the first part of the line which says "created: ".
	$createdDate = Get-Content $file | Select -Index 1
	$createdDate = $createdDate -replace 'created: ',''
	
	# If the extracted text can be parsed as a valid date & time, set the creation time to the text string.
	if ([string]$createdDate -as [DateTime]) {  
		$(Get-Item "$file").creationtime=$("$createdDate")
	}
	else
	{
		Write-Host "Error setting date for: $file"
	}
}
Write-Host "Finished running. Press any key to continue..."
$Host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown")
3 Likes

That (in Bold) is not my specific issue. My concern (and I believe the OPs) is specifically when a Note created in ObsidIan on one device has it’s Original Date changed by Obsidian Sync when the note is synced to another device. Selfishly, I may not be sensitive to your (and other’s problem) of how Obsidian treats 1 or 5,000 notes that are copied/dropped into a Vault from an outside location. I see that as two distinct situations, both worthy of the Devs attention. In my view, two ‘wrongs’ don’t make the result right. Further, I don’t believe this should be a feature request nor should I have to write the code to fix the issue. So, I do agree with your suggestion, at a minimum, for a Setting.

Second this. I also experience this and I thought it was a bug as well. This really bothers me because the creation time (and modification time to a lesser extent) is valuable information for me. They provide contextual information of what I was going through and what level of knowledge I was at when creating the note.

Maybe not many people value them as the same as I don but I think usages like using Dataview to show “notes created today” queries in daily notes (as mentioned by OP) can be useful for some people. Sync unfortunately messes this up by not preserving the creation date of files.

5 Likes

The timestamp of the file is too fragile and can be easily changed for a number of reasons. So I don’t think it’s very reliable. And as far as I know, at least on android, there could be a lot of problems with keeping timestamps. So storing the timestamp in the metadata of the notes might be a simple and easy way to do it.

For example, as this fr points out, obsidian’s file sorting relies on the file system timestamp, so once the timestamp is modified for some reason, the timestamp-dependent file sorting will become completely unusable.

My workflow relies on update times, so it’s important to me to have accurate file update times. I now rely on this plugin to maintain the update times of my files

It would be exciting if obsidian could use the timestamps in the metadata to sort the files.

I can imagine that YAML front matter based timestamps could easily implement a lot of workflows about time

5 Likes

Glad to see this is being looked at. I had created a help topic here Wrong Date Created Property - #4 by I-d-as where I posted a separate screen recording showing this is an issue on a fresh install inside the help vault without Sync. I was pointed in the direction of this post with a suggestion to mention the expanded scope of this behavior. I just made another screen recording (below) attempting to get it to register the different creation times, as I was able to get this to work sometimes. But, unfortunately, in this test, it still showed the exact same creation time, to the second.

WrongDateCreatedWithNoteEdits

I am also happy to see that this is marked as a valuable Feature Request. Considering that it also applies to regular vaults without Sync, I think it is particularly important, especially for people like myself who try to create personal clone local versions of software documentation, attempting to leverage the Date Created sorting in the Explorer Pane, in order to lock in a correct ordering of the files without having to do things like adding prefixes, etc.

Oh my word - I’ve been wanting this for so long

@beaussan Thank you so much for this :pray:

Btw, I noticed a bug where settings disappear

  • I can’t remember if it was when I entered a funny date format or selecting a different read format
  • I just removed the plugin, restarted and added it back and it was fine

Once again. Thank you for this!

Is this still being looked at?

I also find this issue to be pretty irksome. I don’t want to resort to maintaining created and updated time frontmatter fields. It’s redundant and ugly.

This problem is solely due to Obsidian Sync right? I might switch to syncing with my own fileserver if it avoids this.

I think it’s important to protect the file metadata because that enables interoperability with all other tools, GUI and CLI, that a user might want to use to interact with their vault.

2 Likes

I set up my vault on a new machine today via Obsidian Sync, and all the file creation timestamps are “today” instead of the original file creation, weeks or years ago… This means all sorts of queries are completely broken :cry: :cry:
Maintaining the creation timestamp is pretty critical in that use case.

1 Like

Be aware that creation dates often are not preserved even without using Sync. I linked to this above, but here it is again: Wrong Date Created Property

Hopefully things have improved, but I haven’t been keeping track, because I didn’t want to put too much faith in it and be potentially disappointed. So perhaps there may be better handling now.

In the meantime, it is best to use templates with a created value.

I can confirm that this indeed is the case. My experience is that Obsidian is applying some internal process that is changing the file’s creation date under-the-hood whenever I modify a note. As others note, it renders Dataview queries that rely on the creation date useless. Our choices are really only to maintain a cdate field in the frontmatter or encode a timestamp in the note name (in the manner of a ZK note, for example.) The latter is what I do, e.g. 20230529062543 Foo bar note.

I then run a user agent that finds files in the Obsidian vault directory that were “created” in the last n minutes, then parse the timestamp out of the note name and use that to reset the creation date.

#!/bin/bash

OBSDIR="/path/to/my/obsidian/vault"
FILES=$(find "$OBSDIR" -type f -newerBt "$(date -v-15M)" | grep -E '[0-9]{14}')

if [ "${#FILES[@]}" -gt 1 ]; then
	echo "Obsidian has ${#FILES[@]} ZK files with new creation dates."
fi

IFS=$'\n'
for FPATH in $FILES; do
	FN=$(basename -- "$FPATH")
	ACTUAL=$(echo "$FN" | sed -E 's/([0-9]{4})([0-9]{2})([0-9]{2})([0-9]{2})([0-9]{2}).*/\2\/\3\/\1 \4:\5/g')
	setfile -d "$ACTUAL" "$FPATH"
done

Note: macOS only as setfile is included in the macOS command line developer tools.

I really hate that this is necessary, but the file creation date should not be subject to change inside Obsidian.

1 Like

Obsidian sync tries to preserve the creation date. Some filesystem do not support a “creation date”, we can’t preserve it there. The long term solution is to handle note dates internally and not rely on the filesystem

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.