Smart Rule to add date to filename doesn't always work

I have a very simple smart rule to add a document date to a filename:


Most of the time, it works great and adds the date detected in the document to the beginning of the file name, for example “Receipt.pdf” will become “2022-01-20 Receipt.pdf”, assuming that the date 1/20/2022 is somewhere in the receipt.

However, I often print out emails from the Gmail web client directly into DT (Pro 3.8), which look like this:

Invariably, DT cannot detect the date in these emails, and when I try to use the smart rule on, for example, “Test email.pdf”, the filename doesn’t change.

Can the date recognition be improved for such files?



All Databases as a search target and Size is not 0 is a very dangerous combination.
You should be much, much more specific in the target and criteria you apply.

And even if this is just using the On Demand event trigger, you should get in the habit of more safe constructions in smart rules.

What browser are you printing out of?

Safari in this case.

Do you have a recommendation for how I should change the search target predicate?


Here is an example of the test smart rule I just made…

Note it’s a specific Inbox of a specific database, looking only for PDFs with words in them.

I also just printed a PDF from Safari to this Inbox and it changed the name as expected.
What OS are you running?

1 Like

Big Sur 11.6.2. I don’t yet trust Monterey. :slight_smile:

I just made that change you indicated. I still get the same results, it works on most files, but not the email in question.

Does it work on other emails you print from Safari?

In most cases, when I print an email, I end up having to add the date manually. It’s an annoyance. If I tell Safari to include the headers and footers, then it can pick up the date from there with no problem. Maybe I’ll just to that going forward. But it’s a mystery, I thought it’s perhaps a result of the use of the three letter abbreviation for the month.

Ugh! I so detest mail in a browser :confused:

I just ran another test with no headers and footers. It detected the date and renamed as expected.

Stay tuned for the next release.

_is _ there a date anywhere in the text of the email? If not, how could DT possibly find a date without having recourse to the headers?


@chrillek The date is in the upper right of the printed email.

1 Like

Could you send a not working PDF document to cgrunenberg - at - Thank you!

Can you copy and paste the date from the PDF? @cgrunenberg could regional/language settings in macOS influence whether DT recognises the “day_verbose, month_verbose day_numeric, year_numeric” pattern?

In most cases (like this one) this doesn’t matter.

1 Like

@cgrunenberg Sent, in your inbox.


@Blanc Copy and paste work fine. My regional and language settings are for US English, and US date and time styles.

Thanks for the sample! It’s unfortunately an issue of the PDF, the date is on separate lines in the text layer and that’s not recognized. Not sure if it’s caused by Gmail or MailPlane, maybe PDFs generated e.g. by Safari will work as expected.

That’s what I assumed; why did copy&paste work without ado then? I had assumed - wrongly? - that c&p would show that up by pasting a result which mirrored the plain text of the PDF, so in this case was spread across 2 lines.

Just to confirm: I didn’t have an issue with a PDF printed from Gmail’s web UI in Safari.