Hi. I’ve got a metadata field of type “Date” with a custom format of “EEE MMM dd” (e.g., “Wed Aug 22”), and an outline view set to display that field as one of its columns. I’ve discovered that when I’m using the Enter and Tab keys to edit various fields in my outline, and I enter and then leave edit mode for a value in that column without making any changes (e.g., by just tabbing the active edit target through it), the date’s month and day stay the same, but its year resets to 2000. Even though the year isn’t displayed in this format, I can tell because the day of the week changes to whatever weekday went with that date in 2000 rather than in 2018.
What’s happening seems clear enough: Entering and leaving edit mode for that field triggers Scrivener to parse and save the current displayed text value, and since my display format lacks a year, it assumes its default year of 2000.
A related problem is that I can’t use the text field to tweak a date (say, from Aug 22 to Aug 24) without resetting the year to 2000.
Suggestions:
Detect whether the field value has been changed, not just touched, and leave the stored value alone if it hasn’t.
Don’t change undisplayed portions of the date (e.g., the year) that are not explicitly changed by the user. Assume a default of “What was there before” rather than 2000.
When creating a new date object, the current year will generally be a better default guess than 2000.[/list]
Thanks for the report. I can reproduce the problem with fields using time zones and not, so it seems related purely to lack of inputing a year into the field when editing it.
This is might be a difficult one to solve, given a few different factors. For one: how freeform custom formats cannot be easily masked for when interpreting dates. The system that we use to interprete what is typed in is much more limited than the system used to display a stored date, if that makes sense. What we’ve done is added a number of common masks on top of the built-in interpreter, that intercepts what you type in, formats it in a way the underlying interpreter can read, and then sends that. Hence, every custom mask we add is truly that, hard-wired.
And I would bet the second part of what makes it difficult to solve is that merely activating the text field is technically editing, and once that has been done the value as printed is different from what is stored—we can’t say that the year was left alone because technically it wasn’t—the year was changed to “nothing” just by activating the field, and so a default is dropped to 2000.
That all said, it’s a valid issue for sure, so we’ll do our best to get it fixed. Just pointing out a few of the challenges when you have a freeform input field with a freeform output mask all on top of a rigid system that isn’t freeform.
I do agree that this year is a better default than 2000 at any rate, but actually figuring out that a year wasn’t provided (whether explicitly or implicitly) and supplying the current year to the interpreter is where things might get tricky, when you consider all of the dozens of ways a year might be supplied—or not.
P.S. If you can get away with it, add the year. I know it’s maybe clutter, but if the year matters, and if the day of the week matters then technically so does the year, then it makes sense to ensure the year is a part of the information involved in input. Or maybe if the actual day of the week doesn’t matter then in most cases (leap days aside), then the year doesn’t really matter; all that matters is 22 Aug. Just some suggestions for getting around the problem as it currently exists.
I would also add for the benefit of anyone else who might read this, that the century can matter, too. I ran into this problem while using Aeon Timeline with my historical novel, Even though the Scrivener date field was displaying the year, it was only displaying 2 digits, so all my dates in the 1880s got moved to the 1980s. ( Nearest past century with those last 2 digits.) If you’re writing science fiction, it would be a problem in the other direction… but if you’re doing anything with a date outside the range 1918-2018 I’m willing to bet a two digit year mask is a problem.
I’m a Physics professor, and I’m (ab)using Scrivener to do my course planning. I write and organize my day-by-day class plans as folders containing text snippets that describe activities or lecture bits, and I then select and Export a day’s folder to generate my in-class teaching notes printout. I’ve also got a folder for the syllabus, with its own export format. And class handouts. Scrivener is amazingly useful for keeping such a collection of material together and hierarchically organized, with various kinds of print-ready output easy to generate. I can even include nicely typeset equations by way of Services menu integration with the LaTeXiT app.
I’m using an outline view of all the class day folders (collapsed) as my strategic view of the class topics across the semester. That’s where I’ve got the custom date field, to represent the class day. Real estate is somewhat precious, so I’m averse to displaying the year; I think I’d rather just work around the 2000 bug when necessary. And the day of the week is valuable information, 'cuz it’s much quicker to parse where I am in my MWF or TuTh rotation.
None of that is particularly relevant to your technical challenge, of course, but I thought you might be tickled to hear of a completely unexpected use case for Scrivener.
This should be fixed for the next update. It turns out that Apple’s date formatter (which is used as the first port of call to try to interpret the date from the text, in the case where the text matches the expected format) can have a default date set. When a default date is set, then that date is used for any components that are not part of the format. So, I have made it so that the formatter uses the original date as the default date for editing. This means that if you edit a cell and do not change it before moving on, everything works as expected and the year no longer resets to 2000. Likewise if you edit the date and keep the expected format, e.g. change “Thur Sep 20” to “Fri Sep 21”, all will be god and the year will be maintained. If you type the date using a different format, though (e.g. 12/12), Scrivener’s more general date interpretation comes into play and you may not get expected results. Still, this should fix the main issue at hand.
Thanks for sharing your use of Scrivener, by the way! That is very interesting and novel use of the outliner!
