From Glen.Seeds@Cognos.COM Tue Sep 29 15:29:02 1998 Received: from sotr0087.cognos.com (gatekeeper.cognos.com [205.210.232.66]) by dkuug.dk (8.8.7/8.8.7) with ESMTP id PAA06173 for ; Tue, 29 Sep 1998 15:28:59 +0200 (CEST) (envelope-from Glen.Seeds@Cognos.COM) Received: by sotr0087.cognos.com with Internet Mail Service (5.5.2232.9) id ; Tue, 29 Sep 1998 09:28:30 -0400 Message-ID: <650FF9D8BB62D111A48200805FE6469C01B582D2@sotr0081.cognos.com> From: "Seeds, Glen" To: Ted Baker , OblingerJT@csd.npt.nuwc.navy.mil, jason_zions@interix.com, sc22wg15@dkuug.dk, "'Jim Isaak'" Subject: RE: (SC22WG15.1325) RE: (wg15tag 2134) (SC22WG15.1324) (wg15tag 2 130) (SC22WG15.1322) RE: (wg15tag 2129) (SC22WG15.1321) FW: (SC22.1318) R EQUEST TO WG CONVENE RS [Fwd: FW: Year 2k] Date: Tue, 29 Sep 1998 09:28:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain I agree that all date/time representations have limitations. There is one, though, that has significantly fewer limitations than any other I have seen in common use - the ISO format: ...yyyy-mm-ddThh:mm:ss.fff... (UTC) This format can accurately represent dates and times in all ranges of commercial interest. It most significant limitation is that doing arithmetic on it requires first converting it so a number of seconds or days, which consumes compute resources, and requires the converter to have an accurate understanding of the conversion rules. However, since these conversion rules are the same for everyone, it at least puts everyone on the same footing, and is completely portable. Note that the year portion is not a fixed number of digits - it is the number of digits required to represent the actual year number in decimal form. Note the fractional second section is optional, and can use as many digits as required to represent the desired precision. Finally, note that dates in this format can be compared without converting them, which avoids the need for most of the conversions that would otherwise be required in real applications. /glen > ---------- > From: Jim Isaak[SMTP:Jim.Isaak@digital.com@scc.ca] > Sent: September 28, 1998 11:28 AM > To: Ted Baker; OblingerJT@csd.npt.nuwc.navy.mil; > jason_zions@interix.com; sc22wg15@dkuug.dk > Subject: (SC22WG15.1325) 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] > > 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 >