On 8-May-2018 6:53 am, dpb wrote:
On 5/7/2018 12:06 PM, GS wrote:
...

If the source data is indeed StringText then you're at the mercy of
Excel interpreting as per system date format and the resulting
ambiguity. Using textual date formats ("May 05, 2018") will ALWAYS
display correctly because Excel will indeed treat them as text. (ergo
not useable in formulas by direct ref to the cell)
...

Yes, but sometimes with foreign systems one doesn't have the ability
to change the output form...sad, but ime, more often than one would
think, still all too true for specialty systems from a hardware vendor
or the like that are just simple prepackaged demos of how to use the
system but also ime, probably 70-80% of the clients would never have
written a better tool for their purpose but instead just make do with
the toy sample from the vendor and live with the warts.

Been burnt too many times.... :(

--


slightly off topic..

I've been following this thread and have learned things that will help
when I encounter date problems in excel and VBA which I often do.

But what amazes me is that we persist in using these two date formats -
d/m/y and m/d/y. It seems absurd we accept conventions that are
blatantly so ambiguous! And, especially, their continuing use by
software engineers who are expected to think logically. I'm always
coming across applications or data where I have to struggle to work out
which is being used.

d/m/y and m/d/y are not formally internationally accepted date formats
and I'm surprised that there hasn't been a trend towards a more rational
format, such as yyyy-mmm-dd. The very least is a format where the
elements have increasing or decreasing significance - unlike m/d/y which
is neither.