The implications of VBA trying to arbitrate dates by reference to your
regional settings are really pretty horrendous: it would add a level of
complication that, as a programmer, you really wouldn't want to have to deal
with. Eg, what happens when you're talking to an SQL system, where the SQL
standard (which is a non-Microsoft issue) specifically precludes using
dd/mm/yyyy? You'd end up with VBA formats flipping back and forth according
to assumptions about context.

The good workaround is to use non-ambiguous date formats in all contexts.
ISO 8901 is ideal, because it's language independent and is recognised by
pretty well all current software including SQL. Or use dd-mmm-yyyy, which is
also non-ambiguous (at least within the English-speaking world).




"stephenb" wrote in
message ...

Thanks Tom. But why in this technological age would sophisticated
software assume English (US) if I have regional settings of English
(Australia) and I have formatted the cells as dd/mm/yyyy? Did you try
the test I refer to? Even if it is not a bug, surely there must be a
workaround.
Best Regards
Steve


--
stephenb
------------------------------------------------------------------------
stephenb's Profile:
http://www.excelforum.com/member.php...o&userid=28726
View this thread: http://www.excelforum.com/showthread...hreadid=484187