On 05 Sep 2013 12:58, rob@xxxxxxxxx wrote:
Another thing to consider in using LOCAL and hoping you have that
set to mmddyy is have you set up the error trapping for dates that
fall outside of the range limited by the automatic conversion to
MM/DD/YY?
There is that potential problem. Yet not using LOCAL also is often a
problem for the users. Well... unless wherever the presentation is
made, makes *conspicuous* in its presentation, which format of the
two-digit year format is being used. Without that, a user is easily
confounded by what might be *incorrect* information. For example:
I use *YMD, many in Europe or those not native to the USA use *DMY,
and most USA-centric will use *MDY. Each user expects that what they
use\prefer, will be presented to them. Thus if the string 09/05/13 is
presented to a user of each of those formats irrespective their preference:
presented to those expecting *YMD, see that as 13-May-2009;
presented to those expecting *DMY, see that as 09-May-2013;
presented to those expecting *MDY, see that as 05-Sep-2013;
Those have some obviously different meanings. So unless there is a
visual notification\reminder that the date value presentation is in the
form *MDY vs presented in the form expected per locale\preferences, the
date can be ambiguous as possible; i.e. valid irrespective of order of
the individual portions YY, MM, and DD. That can lead to problems. At
least when the date is conspicuously incorrect for a user's preference,
they can infer the date format is not what they expected.
p.s. For a long time I used *DMY as my preference in the USA, and I
had to laugh every time my employer's holidays were applied to my
calendar. That is because my /Independence Day/ was scheduled for
07-Apr each year! The script that added the holiday date used character
literals in the *MDY form, and the software was unaware of that, and
just presumed that the literal date was in *my* preferred format. Yet
oddly, if any date would have been invalid [holidays after the 12th in
any month], the software implicitly /adjusted/ its interpretation of the
date to *DMY, such that no error was issued. The literal date 12/25/07
was implicitly inferred to be 2007-12-25 even though according to my
preferences the date should have been interpreted as 12-Err-2007; i.e. a
month=25 is obviously invalid.
midrange.com
