Year 2000 Conformance of Empress Software Products

This report describes in detail the compliance of the Empress Software products with all four rules stipulated by the British Standards Institute in DISC PD2000-1 A Definition of Year 2000 Conformity Requirements.

Rule 1: No value for current date will cause any interruption in operation.

Empress RDBMS has 9 different formats for DATE and TIME attributes. Tests were performed to show that all DATE and TIME data types can store times and date values that refer to the years in 21st century. Empress RDBMS stores data always in a full year format (i.e. 4 digits) no matter which of 9 different DATE and TIME data type formats are specified.

The nine different DATE data are:

     Type  Format                Example
     -----------------------------------------
     0     yyyymmdd              20000627
     1     dd aaaaaaaaa yyyy     27 June 2000
     2     aaaaaaaaa dd, yyyy    June 27, 2000
     3     mm/dd/yy              06/27/00
     4     dd/mm/yy              27/06/00
     5     dd aaa yy             27 Jun 00
     6     aaa dd, yy            Jun 27, 00
     7     mm/dd/yyyy            06/27/2000
     8     dd/mm/yyyy            27/06/2000

Even in the case of types 3,4,5 and 6, Empress adds the two century digits "19" or "20") to the date field and stores 4 digit year in the database (e.g. 27/06/00 ==> 20000627).

The potential confusion as to which century is being represented by a 2 digit year number might arise in the future if there is no standard to define it. At the moment, there is an "X/Open" suggestion to let date values in the range [69-99] refer to the years in the 20th century and date values in the range [00-68] refer to years in the 21st century.

X/Open standard is a standard that defines the features and functions required for Unix systems, so that these Unix systems remain unaffected by the Year 2000 transition. Empress Software is particularly interested in supporting Unix standards due to the fact that Empress RDBMS runs mostly on Unix platforms.

However, by setting Empress variable MSDATELIMIT to 1968, Empress RDBMS behaviour (and different Empress interfaces) could be tuned according to this X/Open suggestion. Hence, there will not be any changes needed on Empress part if this suggestion becomes a standard.

Tests that INSERT, UPDATE, DELETE and SELECT different DATE and TIME values were performed to satisfy Rule 1 request.


Rule 2: Date-based functionality must behave consistently for dates prior to, during and after year 2000.

Different tests were performed to show that Empress RDBMS could manipulate, calculate and represent dates and times of different centuries in the same database.

• Tests with different SQL commands using expressions and operators applicable on DATE and TIME attributes, such as:
  

  SELECT ... FROM TABLE t 
             WHERE attr1 
             RANGE now TO now + 5 years

• Tests with aggregate functions, such as:
  

  SELECT MAX(attr1), MIN(attr2) 
         FROM TABLE t

• Tests with date arithmetic, such as:
  

  "31/12/1999 23:45:45" + 2 days
  "01/01/2000 00:00:01" - 2 seconds

• All built-in functions that operate on DATE and TIME attributes were tested. for example:
  

  SELECT yearof(attr1), monthof(attr2), 
         secondof(attr3) FROM t

• Different Empress features that affect TIME and DATE attributes were performed, such as: indexing, sorting on TIME and DATE attributes, etc.

Empress RDBMS does NOT use any of DATE or TIME values for a special meaning, such as "99" signifying "end of file" or similar.


Rule 3: In all interfaces and data storage, the century in any date must be specified either explicitly or by unambiguous algorithms or inferencing rules.

As mentioned before, Empress RDBMS stores DATE and TIME data internally ALWAYS in 4-digit year form. For those DATE and TIME data types that allow inserting 2-digit year data, Empress can accommodate any inferencing rule that will be valid by the year 2000. The rule suggested in BSI DISC PD2000-1 standard (i.e. "two-digit years with a value greater than 50 imply 19xx, those with a value equal to or less than 50 imply 20xx") can be easily satisfied by setting the Empress variable MSDATELIMIT to 1950.

Empress Software Inc. is in the position to amend its installation script so that this rule is upheld by default. At this moment this condition is user definable.


Rule 4: Year 2000 must be recognized as a leap year.

Empress RDBMS recognizes year 2000 as a leap year. Test were performed to verify this, such as:

  INSERT INTO t VALUES ("29/02/2000")

or "arithmetic" test,

  "28/02/2000" + 1 day

NOTE: Tests were performed utilizing the following Empress interfaces to demonstrate the compliance with the standard:

Interactive SQL
Embedded SQL
Dynamic SQL
mr-routines
mx-routines
Empress 4GL
Empress ODBC Interface

DISC PD2000-1 08/11/97

More...

BSI DISC PD2000-1 A Definition of Year 2000 Conformity Requirements

Empress Software Year 2000 Certifications