I’m not entirely sure if this is new with Sonoma or just a recent update to DevonThink, but I can no longer input dates properly in the custom metadata “Date” field (via the “Date” column in the file list). I make extensive use of this field and so far I’ve always been able to just copy & paste a date from a document into that field and it would respect my system settings. So “05.09.2023” would convert to “Sep 5, 2023”. Now it converts to “May 9, 2023” (so it flips day and month, US-style.) I also often type shorthand to speed things up (e.g. “5 9 23”) and that used to work perfectly, but same issue now. Bit of a show-stopper at the moment since my whole filing system makes extensive use of this field and I now need to think in a foreign format to keep working. A haven’t made any changes to my Mac’s settings/software apart from the Sonoma upgrade, so I assume that’s where the problem stems from.
Thank you for the feedback! The input of date fields is actually controlled by the system, DEVONthink does neither handle this nor did the recent update change this. Maybe it’s related to your primary system language English (US)?
Huh! You’re correct, it seems to be that. I dragged English (without “US”) to the top and it now works as expected. I assume that this is some change introduced in Sonoma since I haven’t touched the settings in that view for years. Thanks for the hint.
@BLUEFROG Yeah, weird. I don’t understand why it would use “Preferred Language” over the specific “Date format” setting.
I recently upgraded to Sonoma and am experiencing a similar issue. I have a Smart Rule which automatically adds a date to a file name, using the string %recordAdditionShortDate%
I had this configured before so that it would spit out “2/15/24” but now the system preferences have it as “2024/02/15”. Will I need to change the global date format through System Settings, or is there some other way that I could format the date as I had it before?
Thanks, that pretty much gets me where I want to be. It seems like there’s no way to pull a single-digit (i.e. not “zero-padded”) value for month and day, but that’s not such a big deal to me.
Date fields are decimal numbers since a certain date, not text, aren’t they? That’s why different formats work. How formatted only a detail how presented? Or am I wrong on that? I did a test in DEVONthink and that’s how it seemed. That’s how databases and spreadsheets work. So presentation format shouldn’t matter, if someone uses a text field and puts in a date, then it will sort per the text not date.
In any event, I always use DD-MMM-YY format with the month written out as I’m frequently confused about 10/2/23 vs 2/10/23 is or is not the same date, and then because many of us lived through the Year 2k “crisis” even “23” without a century prefix causes confusion.
Date fields were decimal numbers since a certain date. In many environments. Nowadays, they are hopefully just abstract data types representing a Date, i.e. an absolute point in time. The idea of representing a date as milliseconds elapsed since 1-1-1970 in a 32-bit number proved to be a bit problematic, after all
If a field (as in the first post in this thread) is of type Date, you’re kind of right – format shouldn’t matter, as it’s only representational.
OTOH, how does one get the date into the field? (Again: that was the problem of the first post here). You can do that programmatically, aka in a script, by passing a Date object. Or hopefully manually by entering a string – which has to be in some format. AFAICT, on macOS the acceptable format depends on the global preferences for date types. Which looks practical on the surface and rises apparently some problems in practice. If they’d offer a standardized date format (like ISO’s), everybody would know where they stand.
But the post I was responding to (Date formats broken in Sonoma? - #6 by spoiltvictorianchild) was not talking about a date field with type Date. Its author wants to add a date to a filename. Which is a string. So the date becomes a string, and then format matters.
The alternative (again: sortable!) would be ISO’s yyyy-mm-dd. Standardized, systematic, and language-independent (your “Jun” is a Turk’s “Haz”, a Serb’s “Јун”, a Chinese’s “六 月” (literally 6th month), and an Albanian’s “Qërshor”). Of course, language independence doesn’t matter if you’re not dealing with people from non-english environments. Sortability might matter, though: In your system, 01-Apr-23 comes before 01-Jan-23.
If sorted by name, of course. But items with dates in the name I sort by date (extracted from the name by a Smart Rule).
And in spreadsheets dates with leading zeros (in a monospaced font/font variant) look more even. But I don’t live in a spread sheet world (mostly), and quoting in a text with leading zeros in a date does not look good. Too technical.
Only true without separators or if an app doesn’t support numerical sorting but both the Finder and DEVONthink do. Meaning 2024-1, 2024-2, 2024-10 are sorted as expected.
