Change Created Date of Document

User avatar
PWR
Posts: 21
Joined: Tue Oct 02, 2018 8:41 am
Platform: Mac
Contact:

Sat Oct 06, 2018 9:53 am Post

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.)

User avatar
AmberV
Posts: 24121
Joined: Sun Jun 18, 2006 4:30 am
Platform: Mac + Linux
Location: Ourense, Galiza
Contact:

Sat Oct 06, 2018 1:42 pm Post

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.
.:.
Ioa Petra'ka
“Whole sight, or all the rest is desolation.” —John Fowles

User avatar
PWR
Posts: 21
Joined: Tue Oct 02, 2018 8:41 am
Platform: Mac
Contact:

Mon Oct 08, 2018 6:01 am Post

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.

User avatar
rdale
Posts: 1954
Joined: Tue Jul 14, 2015 1:07 pm
Platform: Mac, Win + iOS
Location: St. Louis, MO
Contact:

Mon Oct 08, 2018 12:48 pm Post

[deleted, as response was redundant and didn't contribute to the conversation]
Last edited by rdale on Tue Oct 09, 2018 1:35 pm, edited 2 times in total.
FKA: robertdguthrie
AKA: R Dale Guthrie, Robert, Mr. Obscure, and "Oh, it's you again".

User avatar
AmberV
Posts: 24121
Joined: Sun Jun 18, 2006 4:30 am
Platform: Mac + Linux
Location: Ourense, Galiza
Contact:

Mon Oct 08, 2018 2:56 pm Post

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?)


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.

…also that the creation date was already available as a column in the outline view.


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.

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.


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.
.:.
Ioa Petra'ka
“Whole sight, or all the rest is desolation.” —John Fowles

User avatar
PWR
Posts: 21
Joined: Tue Oct 02, 2018 8:41 am
Platform: Mac
Contact:

Tue Oct 09, 2018 6:17 am Post

AmberV wrote: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.


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).

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.


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.

User avatar
AmberV
Posts: 24121
Joined: Sun Jun 18, 2006 4:30 am
Platform: Mac + Linux
Location: Ourense, Galiza
Contact:

Wed Oct 10, 2018 12:45 pm Post

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:

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.


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.

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).


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.

ImageAn older file imported a few minutes ago into a test project.

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.
.:.
Ioa Petra'ka
“Whole sight, or all the rest is desolation.” —John Fowles

User avatar
PWR
Posts: 21
Joined: Tue Oct 02, 2018 8:41 am
Platform: Mac
Contact:

Thu Oct 11, 2018 5:42 am Post

AmberV wrote: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.


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.)

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.


Sounds pretty promising to me 8)

User avatar
AmberV
Posts: 24121
Joined: Sun Jun 18, 2006 4:30 am
Platform: Mac + Linux
Location: Ourense, Galiza
Contact:

Fri Oct 12, 2018 11:00 am Post

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.
.:.
Ioa Petra'ka
“Whole sight, or all the rest is desolation.” —John Fowles

User avatar
PWR
Posts: 21
Joined: Tue Oct 02, 2018 8:41 am
Platform: Mac
Contact:

Fri Oct 12, 2018 12:55 pm Post

AmberV wrote: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?

User avatar
PWR
Posts: 21
Joined: Tue Oct 02, 2018 8:41 am
Platform: Mac
Contact:

Wed Oct 24, 2018 2:28 pm Post