Smart Rule date format recognition

I have a number of documents with multiple dates, all in the format 09Jul20. Conversion to text shows no OCR errors. Dates are not recognized in smart rules.
Is this format not supported by the “document date” and old/new variations?

Correct. That wouldn’t be a valid date.

Is this a format of your choosing, or do you have any control over it?

No control. Used by my Honda dealer’s service software for service tickets/invoices. No idea how common the software is.

Been using Hazel for this, just trying to move as much as I can within DT3.

You should be able to alter the date with either Hazel or DT. If it were me I would do this in Hazel before sending it to DT.

I have not done this but I do not think the AppleScript would be too bad.

I am not sure what that data format string is from the Honda dealer.
Maybe ddmmmyy?

Start a support ticket and send me an example document and what date you expect to glean from it. Thanks!

Kinda. But they use an abbreviated month string. Weird. But anyway, one could get at it from within DT3 with a regular expression like


and then get at the parts of the date with \1 for the day, \2 for the month and \3 for the year. This should be possible in a smart rule, so no scripting required.

However, if one wants a numeric month, there’d be no way around scripting (afaik). And in this case, I’d rather go with JavaScript then AppleScript because of the support for regular expressions in the former. The regular expression remains the same as above, but one needs some code to get at the capturing parenthesis, e.g.

let matches = rec.plainText.match(/(\d{2})(Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)(\d{2})/);
let day = matches[1];
let month = matches[2]; /* see below for numerical months */
let year = matches[3]; /* possibly add 2000 to it */

One could use a simple array containing the month names and then use
monthNames.index(month) + 1 to get the numeric value. If leading zeroes are required, use

 ('0'+(monthNames.index(month) + 1)).slice(-2) 

Off the top of my hat, not tested at all.

1 Like

Or create 12 rules, one for each month, no script required.

I would walk through all invoices and check the abbreviated months and use those in the regex. @chrillek’s guess is probably right though.

Edit: and while I’m at it, IMHO there’s only one proper date format and that is ISO 8601 (reverse date YYYYMMDD).

1 Like

Edit: and while I’m at it, IMHO there’s only one proper date format and that is ISO 8601 (reverse date YYYYMMDD).

I think you meant: MMDDYYYY :wink: :stuck_out_tongue:

Try sorting a list of documents by name that have your format as the name prefix and tell us how that works out for you!

I actually do use that format (which is generally considered an “American format”) and it sorts just fine for me since I’m only sorting on the month in this instance.

Ex. SomeCompany_PAID_07312020

I also do a year end cleaning and put the files into a year group.

All: thanks for the comments. Didn’t think a simple question like this would get so much attention.

Been doing it in Hazel, DT won’t detect it. Not gonna get into regex and/or scripting since I can continue to use my Hazel rules.

see my comment above, Hazel works, was trying to do it in DT3 only if I could use the built-in date functions. With regex and/or script still need to find the specific date, change the format, etc.

Appreciate the help as always, Jim, but while I can delve into regex as a learning experience (and may), my question was just to confirm my suspicion that the format is not supported by DT3’s smart rule. Hazel works and I’m happy to keep that workflow unless DT3 supports the format in the future.
If you still want the doc to play with, let me know.

ALL: TLDR: Sticking with Hazel at least for now.

Indeed, I’d still like to check it out. It’s always good to have external input to see if there’s something we can do better. Thanks!

Ticket #854248 submitted. Thanks!

Appreciated! :slight_smile:

The times I’ve accidentally used that format, was when I hadn’t performed ISO 3103 yet :slight_smile: