From Support Wiki
Year 2000 Readiness Disclosure
Handling the Year 2000 with Centura Products
Definition of Y2K compliance
Y2K compliance is defined by the British Standards Institution to satisfy the following five criteria:
1. Correctly handle dates before, on, and after 1 January 2000 in representation and calculation;
2. Assuming proper configuration, function properly before, on, and after 1 January 2000;
3. Store, retrieve, and display date information unambiguously as to the century;
4. Resolve two-digit year data unambiguously as to the century;
5. Manage the leap year in the year 2000 following the quad-centennial rules.
The methodology used by Centura is described later in this document.
Note: Y2K compliance in Centura products follows the Gregorian calendar and does not adjust for the Julian-Gregorian conversion relating to dates before 1582 AD.
Centura Products and Y2K Compliance
The recent acquisition of Raima Corporation has expanded Centura’s product line for embedded databases. The current versions of these additional products, as well as the current versions of products previously offered by Centura, are Y2K compliant. Information on the behavior of Raima Database Manager, db_QUERY, Velocis, and Raima Report Writer may be found on Raima’s Web site.
The following Centura products have been tested and found to be Y2K compliant. The versions listed are the earliest version to be in compliance. Once a version has been certified compliant, all subsequent versions also get certified.
Product Components First certified version Notes
SQLBase Database Kernel
SQL/API
SQLConsole
SQLTalk
Server Monitor
Configuration Administrator
ODBC Router 6.1.2
6.1.2
6.1.2
6.1.2
7.0
7.0
6.1.2 1
1
1
1
2
2
3
Centura Team Developer SQLWindows/32
Centura Web Developer
Report Builder
Team Object Manager
Object Nationalizer
Object Compiler
DB Explorer
CDK 1.1.1
1.1.1
1.1.1
1.1.1
1.1.1
1.1.1
1.1.1
1.1.2
SQLWindows SQLWindows Builder
Team Windows
Report Writer 5.0.3 PTF 3
5.0.3 PTF 3
5.0.3 PTF 3
Quest 3.0.3 PTF 3
SQLNetwork Oracle Router
Sybase Router
Informix Router
Ingres Router
MS SQL Server Router
ODBC Router
AS/400 Router
(SQLWindows only)
Sybase SQL Server 4.x
(SQLWindows only) 3, 4
3, 4
3, 4
3, 4
3, 4
3, 4
3, 4
3, 4
SQLHost ALL 5
SQLGateway ALL 5
Net.db 1.5 PTF 2
SQLBase Exchange 7.0 6
Notes:
1. Some versions of SQLBase prior to 6.1.2 were Y2K compliant but are not indicated here since a defect in the SQL/API prevented full compliance. The defect was fixed in the 6.1.2 release.
2. Server Monitor and Configuration Administrator were first released with SQLBase 7.0.
3. No claim of Y2K compliance is made by Centura for the non-Centura products or drivers served by the router.
4. These routers are compliant in the above versions of Team Developer or SQLWindows with which they ship.
5. The nature of SQLHost and SQLGateway are that they pass data as they receive it. Thus, they are inherently Y2K compliant and depend upon the compliance of the SQL/API being used.
6. No claim of Y2K compliance is made by Centura for the non-Centura products incorporated in this product other than that of the 3rd-party product supplier.
Problem Summary
Centura products, along with the majority of computer systems, always store dates internally with all four digits of the year (e.g. 1776), even if they were not specified by the application. The fundamental problem that any computer system faces with regard to the year 2000 is that for simplicity of user interface, it is common practice to allow only the least significant two digits of dates to be entered. This is usually done for two reasons; to minimize user keystrokes, and/or conserve screen space.
The common approach taken by virtually all vendors has been to default the century digits internally to the current century wherever it is omitted. This works well when dates only relate to the current century (as has generally been the case since the advent of the computer age). However, as the year 2000 approaches, this defaulting gives rise to two potential problems:
1. Until the current date reaches 1st January 2000, dates entered that actually lie on or after 1st January 2000 will be stored with the first two digits of the years as 19, i.e. as dates in the past. This has obvious implications for systems relating to forward planning.
2. After that time, dates entered that lie prior to 1st January 2000 will be stored as if they were with the first two digits as 20, i.e. as dates in the future. This has implications for systems recording dates in the past.
Centura addresses has addressed both these issues with recent product releases, as described below.
Centura Century Default Mode
This capability provides a first line of defense for applications by introducing automatic century resolution on validation and storage of dates. When this mode is enabled, a simple algorithm is invoked whenever the century portion of a date needs to be calculated to derive the most likely century digits.
Century resolution method
The method is based on one evolved by Oracle Corporation. It uses two figures to derive the century; the first two digits of the current year, and the specified two-digit year. The following table is used to compute the digits of the input date.
Specified input two-digit year:
0-49
50-99
Last two digits of the current year
0-49*
The intended date has the first two digits of the current century.
The intended date has the first two digits of the previous century.
50-99**
The intended date has the first two digits of the next century.
The intended date has the first two digits of the current century.
*e.g. 1900 - 1949
**e.g. 1950 - 1999
Examples:
1. Assume current year is 1996.
* 89 is entered : 1989 is derived
* 05 is entered : 2005 is derived
2. Assume current year is 2014
* 05 is entered : 2005 is derived
* 34 is entered : 2034 is derived
* 97 is entered : 1997 is derived
This feature leaves developers free to concentrate on the more problematic situations within applications (such as birth dates), safe in the knowledge that the simple situations are already taken care of.
Note: this calculation is only made if the century is not already included in the data.
Centura Team Developer
Release 1.0 of Team Developer defaults the first two year digits on entered values to the current century (as documented on page 7-4 of "Developing with Centura Builder"). Centura Century Default Mode is the standard mechanism for release 1.1.1 onwards of Team Developer and will deal with the majority of situations.
For those situations that are not catered for correctly by this mechanism, developers will need to ensure that all four digits of the date are displayed and can be entered appropriately. The obvious case where this is required is that of dates of birth. Using the Centura Century Default Mode, a year such as 48 will be converted to 2048, which is probably incorrect. Developers must ensure that in this small subset of cases, all four year digits are displayed.
Notes:
1. If a literal or a string is submitted to the database and needs to be converted, this conversion is entirely under the control of the backend. For example, in a query such as the following
SELECT COUNT(*) FROM X WHERE InDate > '01-05-95'
the conversion of the string to a date prior to the comparison will depend on the underlying database. SQLBase's behavior is described below; refer to the database vendor's documentation for information on how their interpretation is done. In comparison, the date value in the following SQL
SELECT COUNT(*) FROM X WHERE InDate > :dtQueryRange
will be converted according to the above method before being passed to the database (provided that dtQueryRange is a data field or variable of type date or date/time).
2. Defect 58970 where the first two digits of the year was assumed to be '19' for certain defaulting purposes, is fixed in version 1.1 of Team Developer.
Date display issues
An issue that developers should be aware of is that of date information loss. This can occur when values are written to displayed fields and are then subsequently read from them. Please refer to Appendix A for details.
SQLWindows
Due to the much larger installed base of SQLWindows, use of the Century Default Mode is optional. In all other respects however, its implications and usage are identical to that of Team Developer.
Use of the mode is controlled on a per-client machine basis, and is configured in the WIN.INI file. The syntax is described in the release notes for SQLWindows 5.0.4, and unless specifically enabled in the WIN.INI will not operate, and the first two digits of the year will be defaulted to the first two digits of the current date.
Notes:
1. The above feature is available 5.0.4, and in PTFs 3 and later of version 5.0.3.
2. The defect where the first two digits of the year was assumed to be '19' for certain defaulting purposes, is also fixed in the versions described above in point 1.
Quest
Whenever date fields are displayed, entered or updated in Quest they are subject to the same issues as with SQLWindows. Version 3.0.4 and PTF 3 of Quest 3.0.3 also contain both the Century Default mode and the defect fix, as implemented in SQLWindows and described above.
SQLBase
Centura Century Default Mode is optional within SQLBase. It is controlled at the server level (i.e. for all databases on a specific server) by a setting in the SQL.INI file. It only affects values that are submitted as strings for insert or update of date values either as literals or as bind variables.
The syntax in the SQL.INI is as follows:
CENTURYDEFAULTMODE=1
If the value is set to 1 as above, then Centura's Century Default mode described above is used. If the value is set to 0 or the line is omitted then the first two digits of the year is always defaulted to the first two digits of the year of the current date. This is set at the server level.
Notes:
1. The above feature is included in SQLBase 7.x.
2. Values submitted as bind variables defined as date/time are never converted in this way, since they are converted to complete date values within the client application.
3. SQLBase defect 58271, where the current first two digits of the year was assumed to be '19' for certain defaulting purposes, is fixed in the following releases: 6.1.1, 6.1.0 PTF 4, 6.0.1 PTF 8. Even if customers do not wish to take advantage of the Century Default Mode, they should update to at least this release before the end of 1999.
Centura router products (SQLNetwork, SQLHost, SQLGateway etc.)
SQLWindows or Centura Team Developer Applications that use SQLNetwork or SQLHost components will face being no special issues; date/time values are set according to the rules described above before being passed to the routers. Programs accessing these products (e.g. SQLHost) directly will do so via the SQL/API (see below).
SQL/API
Since the only database related issues concerning the date conversion happen on the backend server, in general there are minimal SQL/API issues. The only known API issue is related to the use of the sqlxpd() function. At present this is hard coded to assume the first two digits of the year is '19' if not specified in the picture, rather than using the first two digits of the current date. This is logged as defect 59576, which is resolved in the version of the SQL/API supplied with SQLBase 6.1.2 and higher.
Recommendations
Centura Software Corporation recommends that Century Default Mode be used in all applications. We also strongly recommend that to eliminate confusion in applications, all four digits of the year be displayed wherever possible. However, users should not be forced to enter all four digits; interfaces should allow for only two digits to be entered, with the system expanding them on validation to show the defaulted value.
This can be easily achieved with Centura Team Developer and SQLWindows by defining a date/time format for all date fields that allows four digits, such as MM-dd-yyyy.
TeamWindows/Team Object Manager
The only use for date/time in these applications is in recording time-stamps for events. Since there is no user input or update of dates, there are no known issues relating to these products.
Appendix A
Date data loss issues with SQLWindows and Centura Team Developer
When date values are displayed in these products, only the displayed information is retained in the object. Generally speaking this is not a problem, but in some cases it may be.
Example
Imagine a data field dt1 of type date/time with a format of MM-dd-yy, and a section of SAL code as follows;
Set dt1 = SalStrToDate( '4-JUL-1776' )
Call SalDateToStr( dt1, s1 )
After executing the above, s1 will contain '1976-07-04-00.00.00.000000'. This is because the century portion of the date had to be reconstructed when retrieved from the data field. With historical dates, this is not usually a problem, since the century will normally be displayed anyhow.
However, problems can potentially arise in applications under the following conditions:
1. At one location, data can be entered as four digits, and the century is set to a value other than that which would be defaulted.
2. The value is then written to the database.
3. The value is queried from the database into a date/time field in which only two digits of year information are displayed.
4. The value is written back to the database as part of an update statement. The century portion will be overwritten with the default.
Solution
If the situation above exists, the application must be modified by extending the two-digit year data field to display four digits.
© Copyright 1999 by Centura Software Corporation
Last Modified: 19 July 1999 (Y2K-1)
- added reference and link to Y2K statement for Raima products.