Change Created Date of Document

A quick search of the forums shows that many people, like myself, love to use Scrivener for keeping a journal. For my own journaling, I’d previously used Apple Pages, then the command line tool jrnl, then a simple text file delimited with ISO dates with an Emacs mode I wrote myself. I most like Scrivener and actually have my journal project open all the time.

Anyway, a frustration I hit upon when importing my journal was that all the entries had the created date of the date of import. I had read somewhere on the forums that Scrivener uses the file system’s file creation date metadata, so I tried using setfile to change this, but it didn’t work. I think I manually copied each ISO date and time (first line) to the document’s title, then fired up Emacs and edited the .scrivx file, making a quick macro to grab each entry’s title and replace each document’s “Created” tag. This worked, and despite the warnings, editing the .scrivx didn’t do any harm.

Sometimes I’ll want to retroactively write a journal entry (e.g. I’m writing about the day at 1am). Also, when a document is split, the newly created document’s creation date is set to the current date, rather than inheriting its former created date, so this could be years off its real date.

These are the reasons I have for wishing for the ability to change a document’s creation date. I’m sure others have their own. (Not least of all because the average user probably doesn’t want to edit an XML file!)

The macOS Photos app offers a nice example of how this could work from an interaction perspective. The user selects a photo or photos, then Image > Adjust Date and Time… and a dialogue appears with a date picker. (This dialogue also offers a timezone picker, but we can ignore that.)

An option to consider is to create a separate date metadata field used to store the original written date. This is what I do as well for my journal project (and yes, I’m in the camp that thinks it is an ideal tool for the job!). I don’t even have the modification date in the outliner, I have my own date field instead, and that is what I use for searches, sorting and so on.

You can set one up in the Project ▸ Project Settings… window, under “Custom Metadata”.

I realise that doesn’t really address the migration aspects you are talking about. One would have to “hack” the XML to get a custom date field updated just as they would the built-in date field. But as a way of having more flexibility going forward, as well as being certain dates won’t change because the file system did or whatever, it is for me anyway worth the effort of using a dedicated field.

I actually started with a custom metadata approach, but it just became too tedious to set this every day, and this tedium was exacerbated by the existence of the created date just sitting there directly above it in the general metadata section, taunting me… also that the creation date was already available as a column in the outline view.

Granted that this mostly feels tedious because the date-style custom metadata defaults to blank and requires several clicks to get the current date set. (An improvement could be if a date-style metadata entry could optionally default to the current date/time?)

I don’t think there is an issue of the file system changing a document’s existing created date, because I tested this by manually trying to force a file system style creation date change with setfile to no effect. Maybe Keith can weigh in on exactly how Scrivener understands a document’s creation date metadata, but from what I can see it seems wholly governed by the project’s .scrivx XML document.

[deleted, as response was redundant and didn’t contribute to the conversation]

There is indeed an easier way of doing that: type in “today” and forget about the calendar picker widget. You can type in dates using most international standards for doing so, and with a few human friendly aliases like “tomorrow” and “yesterday”.

Do you use macros, like with Keyboard Maestro? If so, note that the Navigate ▸ Inspect ▸ Metadata menu command (or shortcut) can be triggered twice to ensure keyboard focus lands in the first field capable of text entry. Tab will move you between fields. Thus a simple macro that types in “today” for you and returns you to the editor would be possible.

You should be able to add your field to the outliner. It’s a fully editable in that context as well, and otherwise functions just like the two built-in date fields for sorting purposes. With custom metadata you also get much more control over the date string format.

The creation date only matters on import. That part is working for me as expected—I’m not sure why you had different results on your end. I imported a file that was created last month, and it shows 2018-09-07 in metadata.

Once the material has been imported, it uses the XML for managing creation/modification date. The file system will update if Scrivener modifies a content file on it, of course, but otherwise we cannot expect creation/modification as binder metadata to always match the disk. After all, there can be up to five separate files on the disk that represent the collective binder item that we work with as a singular object. So it becomes less straight-forward to think of internal component files as being representative of the whole binder item.

In short it isn’t a file manager, and shouldn’t be expected to make use of the file system like one. It’s an obvious declaration on the surface, but for implications like whether a program manages its own date systems internally, it can be an important distinction.

Thanks for taking the time to offer these suggestions. At the moment all I need to do is create a new document with ⌘N and start writing, which gives me an accurate creation date, so adding the custom metadata is an increase in complexity rather than a decrease, and I’m almost certain I would forget to set the date at least half the time. (I did test out your suggested “today” approach, and although this adds the current date, it always sets the time to 12pm. With the regular creation date I have both accurate date and time.)

I’ve only needed to edit the XML the once, and can’t see this being a regular occurrence in the future, so even if I used Scrivener for journaling for the next 40 years, comparing the accumulated time it would take to manually set an entry date for every day I journaled versus maybe editing the XML once every year or two, my current method wins hands down.

So, taking a step back, given that the only thing adjusting a document’s creation date is doing is changing an XML attribute, what I am suggesting is the ability to accomplish this with Scrivener (rather than with another text editor).

I think there was a miscommunication here. We were already on the same page with Scrivener using its .scrivx XML file to govern document creation dates. The influence of the file system creation date can be considered a red herring.

Okay, it seems like there are two different threads of enquiry. I meant the suggestion of using a custom date field to address this question:

But if as you say ⌘N always provides the result you want, then using the created date field should be fine. For my own journal project I use a custom field, but I have a macro I’ve built that extracts title, date and other bits of information out of the content area (I use a Markdown-style metadata block in the journal text itself) and then inserts each value into Scrivener’s various fields.

As for that part, yes I agree if one needs to retroactively edit dozens or hundreds of entries, and has the ability to do so, editing the XML will be the most straight-forward approach. What still has me confused though is why the file system creation date was not used for the initial import. I.e. ordinarily one wouldn’t have to edit the XML to get a batch import correctly registered in Scrivener’s metadata in the first place. Editing the XML would only be for cases where neither Scrivener nor the file system had the right value, for whatever reason.

[size=80]An older file imported a few minutes ago into a test project.[/size]

But it might not be too hard for us to add the date picker widget to these fields somehow. Back when they were designed as static elements, there was no such easy thing.

There’s a simple answer to this! My previous journal file was a single plain text file, with ISO dates separating each journal entry. Only one file, only one creation date. (I think I used an Emacs macro to add “#” to each date then had Scrivener split it up as Markdown.)

Sounds pretty promising to me 8)

Okay well that explains it then. In that case, a better route might be to split the file up before hand with a script, use that script to scrape any intended creation dates from each entry and use the file system to set those dates with touch. To me that would be easier than having to track down IDs in the XML and changing date values in the binder metadata after import.

As for any kind of controls in the UI, there is no interest in making this anything more than a static field, sorry to say.

No worries. How about the alternate idea — having an option to default a custom metadata date to the current date/time?

Implemented in 3.0.9: