From rinehuls@access.digex.net Wed Nov 4 13:11:47 1998 Received: from ratatosk.DK.net (root@ratatosk.DK.net [193.88.44.22]) by dkuug.dk (8.8.7/8.8.7) with ESMTP id NAA00613; Wed, 4 Nov 1998 13:11:47 +0100 (CET) (envelope-from rinehuls@access.digex.net) Received: from access5.digex.net (qlrhmEbBUV1EY@access5.digex.net [205.197.245.196]) by ratatosk.DK.net (8.8.8/8.8.8) with ESMTP id XAA02917; Tue, 3 Nov 1998 23:51:44 +0100 (MET) Received: from localhost (rinehuls@localhost) by access5.digex.net (8.8.4/8.8.4) with SMTP id RAA13286; Tue, 3 Nov 1998 17:51:40 -0500 (EST) Date: Tue, 3 Nov 1998 17:51:40 -0500 (EST) From: "william c. rinehuls" To: sc22docs@dkuug.dk cc: keld simonsen Subject: SC22 N2834 - SC22 Response on "Y2K Problem" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ____________________ 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: rinehuls@access.digex.net _____________ end of title page; beginning of response _________ From: Bob Follett To: Lisa Rajchel 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 > Lrajchel@ansi.org ----------------------------------------------------------------------- > -----Original Message----- > From: Smith, Michael [SMTP:smith@iso.ch] > 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 __________________________________