Yes !!!

At 12:37 PM 3/25/97 PST, you wrote:
>For NLS and standards conformance reasons, the ADSM AIX and
>Solaris 2.5 clients follow the XPG/4 standard, which uses
>the Locale setting of the operating system to determine date, time,
>and number format.  The ADSM Dateformat, Timeformat, and Numberformat
>options are ignored because of this.  Informational APAR II09664
>describes how to change the Locale settings on AIX that are used
>by the ADSM client.
>
>We do have a bug in our support of Locale, which is reported in APAR IC16007.
>When the length of the Year field in Locale is changed from the default
>of two digits to four digits, some systems can experience a memory fault
>when executing ADSM command-line commands involving years.
>This will be fixed in the current release of the product.
>This APAR made us also realize that there is one XPG/4 dateformat that
>we will never be able to accommodate: the long text format of dates,
>such as Monday, September 29, 1997 (instead of 09/29/97 or some numeric
form).
>We will document this as a restriction.
>
>In the next release of the product, we plan to follow the following
>rules on our XPG/4 platforms:
>
>1) If Dateformat, Timeformat, or Numberformat options are specified, use them
>2) If they are not specified, use Locale as the default
>3) If Locale specifies the one text date format we can't process
>   (e.g. Monday, September 29, 1997), use our default Dateformat
>4) The year field can be specified as either two digits or four digits
>   in all command-line commands, regardless of the Locale length for Year
>
>Would these rules satisfy both XPG/4 and the concerns of customers like
>Dr. Richter and Monsieur De Witte?  We were considering adding them to the
>fix for IC16007 in the current release as well, and welcome your input.
>
>MJ Lopatin
>ADSM Client Development
>
>