(In)consistency of display of dates

[mpmanti]

Can the display of dates across the application please be made more consistent? My preference would be for DEVONthink to follow the user’s macOS system settings or to allow the user to choose a single app-wide default format.

My macOS Ventura 13.4 system settings are for YYYY-MM-DD display of dates and 24-hour display of time.

When my filenames have embedded dates, I use the YYYY-MM-DD format, as that enables sensible sorting on filenames both inside and outside of DEVONthink.

I used the DEVONthink hidden preferences to:

• disable relative dates and to use a fixed-width font, and
• use a fixed-width font in list view.

In DEVONthink’s list view:

• Date added, created, modified, etc., display today’s date and time as 2023-11-10, 14:35 if I adjust the column width appropriately. This is what I want.
• Custom metadata date fields display today’s date as Nov 10, 2023 or Nov 10, 2023, 14:35, depending on whether the date format for the field is set to Date or Date + Time. It also expects input in that format or in mm/dd/yyyy format.

Meanwhile, in the inspector, today’s date and time is displayed for both types of date fields as 11/10/2023, 14:35:00. Since I’m in the US, I imagine DEVONthink is following the US convention here but ignoring my system settings. The inspector also expects dates to be entered in that format.

This might seem like a quibble, but it does have quality of life implications. I often make data entry errors on custom date fields in list view because the display of the built-in date fields has me primed for YYYY-MM-DD entry. Sorting also looks off enough to sometimes take me out of my flow, especially if I switch from sorting on a built-in date field to sorting on a custom date field.

Thank you!

[cgrunenberg]

@mpmanti

Custom metadata date fields display today’s date as Nov 10, 2023 or Nov 10, 2023, 14:35, depending on whether the date format for the field is set to Date or Date + Time. It also expects input in that format or in mm/dd/yyyy format.

This part is controlled by macOS (as these list cells are editable), which system language and which date settings do you use? E.g. over here (German system) the order is different and the month’s name isn’t used. It’s just DD.MM.YYYY like in the other cases.

[mpmanti]

I’m using English (US) language, United States region, and YYYY-MM-DD date format system settings. I’m on macOS Ventura 13.4.

Interestingly, date input in the Contacts app also ignores system settings and expects mm/dd/yyyy input.

I did some poking around online and in ~/Library/Preferences, and the global preferences file appears to be consistent with the system settings panel.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>1</key>
	<string>y-MM-dd</string>
</dict>
</plist>

Per this documentation, 1 indicates the short date format. That seems to be what DEVONthink is using when I narrow the columns on the built-in date fields.

If I widen the column for a built-in date field in list view, it appears to switch to a default for medium format that is based on region. Custom date fields seem to use the medium format regardless of the width of the column in list view.

If I get brave enough, I might tinker with defaults write to set formats for medium, long, and full, and see how they propagate.

[mpmanti]

@cgrunenberg

Following the example here, I got brave enough to tinker with defaults write. DEVONthink does appear to be using the medium format for custom date properties in list view.

blah@MacBook-Pro ~ % defaults write NSGlobalDomain AppleICUDateFormatStrings -dict-add "2" "y-MM-dd"
blah@MacBook-Pro ~ % defaults find AppleICU
Found 2 keys in domain 'Apple Global Domain': {
    AppleICUDateFormatStrings =     {
        1 = "y-MM-dd";
        2 = "y-MM-dd";
    };
    AppleICUForce24HourTime = 1;
}
blah@MacBook-Pro ~ %

Data entry in list view also appears to work as expected.

It would still be handy for list view to dynamically adapt the display format of custom date properties the way it does for built-in date fields.

[cgrunenberg]

@mpmanti

That seems to be what DEVONthink is using when I narrow the columns on the built-in date fields.

The internal dates are not editable in List view, the format depends on the available width and might also include relative dates if not disabled.

Editable custom dates basically depend on the settings in Preferences > Data and the system settings.

[mpmanti]

I understand that internal dates are not editable in the list view. I am using the internal dates something like a control in my experiments.

My findings from tinkering with the system settings via defaults write and reading up on AppleICUDateFormat are:

• There are four (4) system formats for dates: short (1), medium (2), long (3), and full (4).
• Only short (1) can be configured directly via Systems Settings app. The others seem to be determined by language and region settings unless they are overwritten by defaults write.
• All four (4) system formats can be set via defaults write.
• When the column width for the internal dates in DEVONthink’s list view is adjusted, list view switches to using the appropriate system format. Other apps (e.g., Finder) do the same thing.
• When the column width for a custom date in DEVONthink’s list view is adjusted, list view does not switch to using an appropriate system format. It always uses the medium (2) system format, which affects both display and editing in list view.

The above findings seem to be borne out by the effect of tweaking system settings via defaults write on the display of “Date Added” (internal date) and “Record Date” (custom date) in my posts above.

My feedback is that I would prefer the custom dates to behave like the internal dates in list view if that is feasible. That is, the format of the custom dates in list view should respond to changes in column width by applying the appropriate one of the four (4) system date format settings, rather than just always use the medium system date format setting.

I don’t know if the above would be feasible with the methods that Apple exposes to application developers or not.