From Jim.Isaak@digital.com Mon Sep 28 17:28:13 1998 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by dkuug.dk (8.8.7/8.8.7) with ESMTP id RAA02967 for ; Mon, 28 Sep 1998 17:28:12 +0200 (CEST) (envelope-from Jim.Isaak@digital.com) Received: from exceng1.lkg.dec.com (exceng1.lkg.dec.com [16.24.208.32]) by mail11.digital.com (8.8.8/8.8.8/WV1.0g) with ESMTP id LAA03916; Mon, 28 Sep 1998 11:27:57 -0400 (EDT) Received: by exceng1.lkg.dec.com with Internet Mail Service (5.5.1960.3) id ; Mon, 28 Sep 1998 11:28:07 -0400 Message-ID: <7950EC8530E4D1119F690000F863115447E59C@exceng1.lkg.dec.com> From: Jim Isaak To: Ted Baker , OblingerJT@csd.npt.nuwc.navy.mil, jason_zions@interix.com, sc22wg15@dkuug.dk Subject: RE: (wg15tag 2134) (SC22WG15.1324) (wg15tag 2130) (SC22WG15.1322) RE: (wg15tag 2129) (SC22WG15.1321) FW: (SC22.1318) REQUEST TO WG CONVENE RS [Fwd: FW: Year 2k] Date: Mon, 28 Sep 1998 11:28:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Ted, Year 2000 Compliance is defined in IEEE Std 2000.1-1998 .... Its not clear we could revise 9945-1 to require systems to meet this standard (but I know of no UNIX/POSIX systems that do not meet it as "systems" .... applications is a different story.) If we made a change in this area, we should make sure it relates to "conforming applications", since this is where the rubber really meets the road for consumers.) --------- on 2038 the "2038" "dead"line for UNIX/POSIX is well known, and referenced in much of the discussion on this standard ... we might do well to update the POSIX work before then to adjust that window of time ... However, ALL dates have limitations ... that is the nature of dates ... few applications correctly compute dates spaning the year 5BC to 5AD (failing to realize there is no year "0"), folks computing astronomic dates want calanders that handle 10's of billions of years (but are not too sensitive about missing leapyear calculations), and so it goes.. Generic lesson learned (I wish): Every field in an application may have implicit limits (lenght of name, # of digits in the Dow Jones Average, earliest/last date recordable, limit on calculations, etc.) .... These should be documented These should be consistent with the user requirements There should be soft failure for out of range materials ... All of this is "software engineering", as compared with "computer programing" ... something we will need to help the world understand over time. Y2k is "just the tip of the iceburg" as the captian of the Titanic was reported to have said. ;^} thanks Jim Isaak --------- mailto:j.isaak@computer.org or inside Compaq: Jim.Isaak@Compaq.com Internet Best Practices: http://computer.org/standard/Internet Candidate for President of the IEEE Computer Society http://www.tellink.net/~isaak/CSPres.htm