File metadata is not immutable and somewhat fragile, so I don’t rely on creation dates. I could think of a few ways they could be destroyed. I typically have no reason to sort notes alphabetically (although I could appreciate certain constructs that would), but I have several reasons to sort chronologically. For example, just as computers do, my use of notes tends to exhibit locality of reference (the principle of locality) so I’ll revisit recently made notes for a while. I’ll put /./ in the search bar and have a list of my most recent notes since they’re sorting chronologically. I don’t rely on internal timestamps because I find it much more useful to have that timestamp on the file name, as in the example above.
When I’m doing research I’ll copy/paste entire web pages of articles/papers/whatever into Obsidian, where I have the timestamp and the document title in the file name. That timestamp also serves as version control. If a paper is revised, I can copy/paste it again and it will have the same file name title, but a different timestamp. By searching for keywords in a title, Obsidian will find all versions. If at a point in the future I want to keep only the last version, I can see which to delete simply by the list of file names, and they’re already in order.
Another reason all of my Obsidian files have a timestamp is that the timestamp acts as a unique serial number since the stamp goes down to the second (I cannot create more than one new note per second). Let’s say I have two vaults of research and I want to merge them, but there’s a bit of data overlap. The timestamps guarantee that there won’t be any name conflicts / accidentally overwritten files. It also means any internal links within the two sets of data won’t inadvertently create false links due to name collision, because it is guaranteed that there cannot be any name collisions. The merge still represents two sets of data until such time as I create those relationships. Let’s say I have merged two (or more!) vaults and I want to eliminate any duplicate titles even though they have different timestamps. The following Unix/Linux/Mac line command will identify the duplicate titles and how many copies of each are in the vault:
find . -type f | sed ‘s[^.\/[[;s/.//’ | sort | uniq -c | grep -v '^1 ’
I can also easily rely on those stamps to find data added between two dates, before a date, after a date, etc. I can do all of this without having to inspect file contents or rely on filesystem metadata.
If by system you mean Obsidian, whether or not it’s necessary depends upon one’s ontology. I take a much broader view of my data, not only across vaults, but across entire systems. One day Obsidian, too, will go away. Not being Blanche Dubois, I tend not to rely on the kindness of strangers (to write things to migrate my data). I’ve been through enough migrations and data integrations to see value in a bit of considered structure up front so as not to lose data down the road.
Ultimately everyone does what works for them. I just tend to “future-proof” my stuff a lot. Maybe this post will help others make the decision on timestamps.