C'mon Jezebel, is that the best you can do? I would have thought anyone
stupid enough to think '99' was a day or month would know. Since when is
'99/99/99' a date? So, you input garbage, ignoring the field's prompt to
enter "the starting date, in dd/mm/yyyy format" and got garbage back. Wow.
What did you expect? How about posting an example of an error using *real*
dates?

Granted, I didn't include any error checking, but then neither does much of
the VBA code you post in this and other NGs. By your standards that makes
VBA unreliable, or at least many of *your* implementations of it. If all it
takes to satisfy you that field-based date calculations are reliable is for
error-checking to be included, where appropriate, I'd be happy to oblige -
I'll add it to the next release. Given your obvious prejudices, however, I
somehow doubt that any field-based solution will satisfy you, no matter how
robust.

For the OP's purposes, the data validation should exist at the time of entry
into the db/table being used for the mailmerge source, so modifying the
existing field codes for the mailmerge example is completely unnecessary.

As for your claim that you've "never disputed that these codes *can* produce
the right answers", aren't you the Jezebel who previously claimed in these
NGs that:
a) "Word can't do arithmetic with dates (unlike every other Office app)"
(Sep 11 2004).
b) all Julian number formulae have "*extremely* dubious reliability" (Oct 9
2004), i.e. not just my implementation of them;
b) "Calculations are limited to very limited calculations like SUM(ABOVE)"
(Aug 9 2005). Note: the bit between the #s is added for context.
c) "Word has nothing like the SUM() capabilities of Excel. Nor are cell
references so simple" (Feb 7 2006).
Perhaps you should re-read what you're own posts on this topic.

As I said once before, it's a matter of horses for courses. A big plus for
the field-based solution is that it doesn't raise the same security issues
you get with macros.