Subject: SC22 N2834 - SC22 Response on "Y2K Problem"

From: "william c. rinehuls" <[email-masked]>
Date: Tue, 3 Nov 1998 17:51:40 -0500 (EST)

____________________ beginning of title page _______________________
ISO/IEC JTC 1/SC22
Programming languages, their environments and system software interfaces
Secretariat:  U.S.A.  (ANSI)

ISO/IEC JTC 1/SC22
N2834

TITLE:
SC22 Response to the ISO Query on the "Y2K Problem"

DATE ASSIGNED:
1998-11-03

SOURCE:
Secretariat, ISO/IEC JTC 1/SC22

BACKWARD POINTER:
N/A

DOCUMENT TYPE:
Other

PROJECT NUMBER:
N/A

STATUS:
N/A

ACTION IDENTIFIER:
FYI

DUE DATE:
N/A

DISTRIBUTION:
Text

CROSS REFERENCE:
N/A

DISTRIBUTION FORM:
Def

Address reply to:
ISO/IEC JTC 1/SC22 Secretariat
William C. Rinehuls
8457 Rushing Creek Court
Springfield, VA 22153 USA
Telephone:  +1 (703) 912-9680
Fax:  +1 (703) 912-2973
email:  [email-masked]

_____________ end of title page; beginning of response _________

From: Bob Follett <[email-masked]>

To: Lisa Rajchel <[email-masked]>

Subject: Re: FW: Year 2k

Dear Lisa:

Following is the SC 22 response to the ISO Central Secretariat request
for our comments and actions regarding the "Y2K problem." 

For the most part, SC22 standards either provide some capability for
users to handle dates beyond the year 2000 or they are not concerned
with dates at all.  However, since our standards are generalized for use
in a wide variety of applications and environments, the applications
written by programmers using our standards may or may not be Y2K
compliant.  Furthermore, these applications may be dependent on the
limitations of the underlying hardware.  

With this is mind, the following additional comments relate to certain
of our standards:
  --  Ada.  There is no problem with the year 2000 but the limit on the
date type is the year 2099; this limitation is well documented in the
standard.
  --  COBOL.  The current COBOL standard provides 4-digit year support
with the CURRENT-DATE function.  There are other features of COBOL that
provide 2-digit year support.
  --  Fortran.  Prior to Fortran 90, the standards had no date intrinsic
function so that any date-related code was vendor or user generated.  In
Fortran 90 and 95, there is a DATE_AND_TIME intrinsic subroutine which
return a date with a four digit year, as long as the underlying
processor can provide the date as four digits.  If not, the Fortran
processor (compiler) is required to return all blanks.
  --  Modula-2.  The standard allows the year field of the type denoted
by DateTime to be implementation defined on certain small systems with
limited numeric range but also requires that any such
implementation-defined behavior be explicitly described in the
documentation.
  --  POSIX.  Assuming that the definition of the "Y2K problem" is the
rollover from 1999 to the year 2000, there are no known problems in the
POSIX standards.  However, the standards do not prevent a Y2K
non-compliant application that is running on a POSIX compliant system
from failing.  Our Working Group 15 is currently looking at a much wider
set of year related problems and a standard that includes this
information is in the final stages of development.
  --  International String Ordering (now at the FCD stage).  The
informative annex of this standard  includes information about year 2000
compliant comparison of dates.
  --  APIs for Internationalization (now in the Working Draft stage). 
The API for "string to time" conversion will include guidance for year
2000 compliance.

In summary, we know of no provisions in our standards which would
prevent the production of Y2K compliant implementations and
applications using these standards.

While the above observations are accurate to the best of our knowledge,
it should be understood that they are not intended as a year 2000
compliance certification for any of our standards.

Regards,
Bob Follett
Chairman, SC 22

------------------------------------------------------------------------
Lisa Rajchel wrote:
> 
> Please see below a message from ISO Central Secretariat concerning Year
> 2K.  Please let me know by 30 October 1998 if your SC is engaged in any
> activities on this topic.
> 
> Thanks for your help.
> 
> Lisa A. Rajchel
> American National Standards Institute
> 11 W. 42nd Street
> New York, NY 10036
> Tel:  1 212 642 4932
> Fax:  1 212 398 0023
> [email-masked]

----------------------------------------------------------------------- 
> -----Original Message-----
> From:   Smith, Michael [SMTP:[email-masked]]
> Sent:   Tuesday, July 21, 1998 12:15 PM
> To:     LISA RAJCHEL
> Cc:     Lingner,  Klaus-Gunter; Brannon, Keith; Clivio, Sophie
> Subject:        Year 2k
> 
> Dear Lisa,
> 
> Hope you are keeping well.
> In a recent communication, one of the ISO Council members has asked that
> we investigate the full range of year 2k problems, not only with regard
> to our IT implementations. In particular they have received legal advice
> that there may be liability problems associated with the content of
> standards.As an example, ISO (ISO/IEC) may be liable if an organization
> implements a standard which subsequently proves not to be year 2000
> compliant and as a result of which such an organization suffers
> prejudice. It would seem advisable that JTC SCs review the standards
> currently on their books to ensure this is not a problem. By copy I am
> also asking Sophie to contact TC 68, 154, 184  etc. for the same purpose
> and asking Klaus Lingner to bring this to the attention of all the
> technical staff as there may be standards in other fields which may be
> concerned.
> Please could you let me know if JTC 1 has taken specific  actions in
> this respect.
> Thanks and best wishes,
> Mike

__________________ end of SC22 N2834 __________________________________