Odd date formatting behavior in Key Attributes

I noticed a strange inconsistency in the formatting of date fields in the Key Attributes pane in (at least) v8.5 and v8.51.

I changed my system Short Date to yyyy-mm-dd, and Tinderbox respects that when displaying dates (good):

If I click on a date field, pause, and then click again, the field unlocks for editing, with the date in the same format (good):

But if I double click, the field unlocks in a different format which appears to be Medium Date (bad, or at least surprising):

I believe the latter is by intent and was intended to avoid dd/mm and mm/dd order confusions as the month is rendered in text. After saving the desired OS setting is restored.

Could you unpack that ? I think I may be misunderstanding.

(My impression was that dates in the TBX files were always encoded in ISO8601, rather than in any locale-specific form)

When shown as a Key Attribute or in Get Info/attributes a Date-type attribute renders as follows (from aTbRef):

Date-type data. Shows the data and time, with the date/time format in the host OS’ short date format, so this will vary by the user’s locale and their choice of OS settings . Document Settings offer a small selection of variations on the OS format. An alternative date-time string format can be used for all Date-type attributes in KA by setting $KeyAttributeDateFormat at document or note level using a date format string. On entering a date, if no time is specified, the time element of the attribute value defaults to current system time. A date-picker control is offered to the left of the value box. When editing dates in the key attributes table, from v8.2.3 the date string is changed before editing to its value in normal format (medium date, short time). This avoids ambiguity in short dates, where the default US style uses 2-digit years: i.e. does 12/7/41 represent a date in 1941 or 2041?

Note the recent change in v8.2.3.

The formatting in this context has no effect on the storage of date-type data in a TBX (which I believe is unchanged).

1 Like

Ah. As an Australian American working on a UK-US project, I’m sensitive to the date issue, which is precisely why I had the date format set to quasi-Japanese (pure big-endian)! So the basic idea of editing in Medium is not stupid. You might however want to adjust the documentation to describe the actual behavior, which is that a double click gets you Medium and two (well-spaced) single clicks gets you Short. (Please don’t take away the Short mode!)

1 Like

We’ve had all sorts of recurring confusions that arise from the US propensity to use 2-digit years in short dates. For example, if you write 12/7/45, do you mean 1945 or 2045? Each may be “obviously correct” to various users,

So, when editing, we temporarily switch to medium format and remove the ambiguity.

FWIW, where did you look and not find the correct description? IOW, where in the docs needs updating?

This bit from your earlier post:

That’s a half truth - if you double-click on the field, you get that behavior, but if you click once, pause, and click again, you end up editing a Short Date version.

OK, well I guess that’s a bug as ISTM both forms of ‘edit’ should arrive at the same end point - editing the value. @eastgate?

It was certainly confusing to stumble on, but now that I know what’s going on I like having access to the Short Date editing and I hope they don’t entirely take it away.