News:IMPORTANT MESSAGE! This forum has now been replaced by a new forum at http://forum.eastgate.com and no further posting or member registration is allowed. The forum is still accessible via read-only access for reference purposes. If you wish to discuss content here, please use the new forum. N.B. - posting in the new forum requires a fresh registration in the new forum (sorry - member data can't be ported).

I searched to see if this has come up before, but couldn't find a search phrase that works...

I like the automatic input help when entering dates -- e.g. if I put in 12/5, TBX will complete the date and time. Unfortunately the conversion insists on using US format even though all my settings are for the UK: e.g.: 12/5 (the 12th of May) is changed to 5/12 (5th of December). The 23/5 results in "never" of course.

Shouldn't the conversion pick up the date format from the OS settings?

I confirm (using v5.11.1) that my Mac gets the same result. You didn't mention your specific locale setting but I'll assume it's UK - some TB users write/use formats other than their OS settings, which can muddy the waters. The Mac UK-locale short form date is dd/mm/yyyyy, so 5 Dec 2012 is 05/12/2012. My Mac is set to UK locale and does replicate your issue. I'd also read 12/2010 as shorthand for 01/12/2010.

Guessing intended date form text input is a challenge for code, but I'd agree that if locale is UK, indeed anything other than USA/Philippines then day-month order is a more sensible default guess - see why. However, despite that map, my hunch is m/d format users are the larger sub-set of TB users. In fairness, the app's author is American and falling back to one's own native format isn't illogical.

Anyway, I'll report this to support. I suspect it's a matter of reviewing the order the TB tests it's data assumptions.

I'm chiming in because this issue comes up for me every now and again. I'm a US user with specific custom settings that don't conform to any expected standard (ICU yMMdd which presents as YYYYMMDD). OS-level date support would prevent some unexpected (and not always immediately detectable) behavior for agents that filter on date.

I've emailed support and have requested OS-level date support as a feature.

When Tinderbox converts strings to dates, it runs through a long checklist of possibilities. Here's a rough summary, which may explain why things work as they do.

FIRST, we recognize special keywords like "today" and "yesterday". If we find those, we handle them and we're done.

NEXT, we ask the system to parse the date using your local format. If the system can do this, we're done. (This is what Johnnie Wilcox is requesting, and it's already implemented. But the system is not very forgiving of small lapses or missing data, so it's not hard to make the system fail to parse the date.)

NEXT, we try a bunch of hand-written fallback routines. For example, if the system can't parse the date but it looks like an American date, we try that, using a parser that's more tolerant than the system's. This is bad for the UK, unfortunately, as the original poster observed.