Y2K Compliance Statement

This communication is intended to clarify how R:BASE Technologies products deal with dates beyond 1999. This affects all R:BASE products, including Runtime, Personal version, Full Version and Multi-User and all Oterro versions, including Starter and Unlimited versions. However, this document specifically does not cover the Tango portion of the R:Tango product.

All R:BASE databases (Windows, DOS and OS/2) have always allowed for the storing and processing of four digit year data. For that matter R:BASE can properly handle all dates between January 1, 3999 BC and December 31st, 9999 AD. This means that if a DATE field is entered into the database using four digits for the year the R:BASE engine can record the year accurately, with all four digits being stored, regardless of the century. However, it is worth noting that this feature is not enabled by default in versions of R:BASE prior to R:BASE 2000.

To determine the Y2K status of your Database you will need to issue the SHOW DATE format at the R> Prompt in R:BASE while connected to the database you wish to check. This will result in one of the two following types of output:

DATE format   MM/DD/YYYY
DATE sequence MMDDYY
Century threshold YEAR is  0
Default CENTURY is 19

DATE format   MM/DD/YYYY
DATE sequence MMDDYY

The version on the left with four lines will be seen by those using versions 5.5 and higher. The version on the right will be seen by those using 5.0 or older. Your results may not match exactly in format or alignment.

It is very important to note that changing ANY of these settings will have no impact on data already in your database. To change data already stored in the database you will need to pull the date out of the database, manually reprocess it, and reinsert it into the database. It is also important to note that you must change these settings while connected to the database you wish to affect since these settings are stored inside the database and are database specific. Once set these will affect all R:BASE products that use that database including Runtime and Oterro. It is also worth noting that your RBASE.CFG or Oterro.CFG file settings will be ignored in leu of the settings in the Database.

If your database only shows the Date Format and the Date Sequence and does NOT show the other two lines then your database is NOT fully Y2K compliant as 2 digit years will always be interprited as being between 1900 and 1999. This is also the case if your Date Century and Date Year are set to 19 and 0 respectively.

To explain...

The Date Sequence affects storage. When set to MMDDYY R:BASE will store information in four digits. This is the prefered setting. The problem comes if you set the Date Sequence to four YYYY's as ALL dates entered will then be interprited to be 4 digit years. For example 1/1/99 would be seen as January First in the four digit year 0099. This is known as the first century date problem. Dates entered in this fashion will sort before dates in the 1900 and will need to be manually reprocessed before you can use them as intended. This happens most often if you intend to set the Date Format and use the SET DATE MM/DD/YYYY syntax as this syntax affects both settings at once. To affect only the date sequence use this command: SET DATE SEQUENCE MMDDYY

Date Format affects input and output of date data. For example setting Format to MM/DD/YY would allow R:BASE to see 1/1/99 as a valid date but would not allow R:BASE to see 1/1/1999 as a valid year. Whereas setting Format to MM/DD/YYYY would allow either date to be properly interprited according to your DATE YEAR and DATE CENTURY settings (in R:BASE 5.5 or higher). As noted above setting Date Format by using the SET DATE MM/DD/YYYY will affect both Sequence and Format. Use SET DATE FORMAT MM/DD/YYYY to affect only the date format.

In R:BASE 5.5, as well as all subsequent versions, a new capability was introduced which allows for the use of two digit dates outside of the 1900's. Prior to this version 2 digit dates were always assumed to between 1900 and 1999. Now you are able to slide that 100 year window to any place on the AD timeline that R:BASE supports. This feature consists of the remaining two parts of the Show Date command, both of which must be set properly to utilize the "Two Digit Compliance" of your product. The first is the Default Century and is set by default to 19. This setting will not need to be changed except for clients who wish to enter data that does not span 1900 and 2000. The second half is the Default Year and is set by default to 0. This is left at 0 so as not to break existing applications. By using these two settings you can configure R:BASE to allow entry of 2 digit dates in any given 100 year range. The default, when set to 19 and 0, is to operate from 1900 to 1999. To set these simply issue the SET DATE YEAR ## and the SET DATE CENTURY ## commands at the R> Prompt while connected to the database.

Assuming you set the default century to 19 and the default year to 50 the following results can be achieved:

• Any two digit year entered as a value of 49 or less will have 2000 added to them. Thus the value 25 will be stored as 2025.
• Any two digit years entered as a value of 50 or greater will have 1900 added to them. Thus the value 95 will be stored as 1995.

It is very important to note that the Century and Year functions will ONLY affect interpritation of new Data being entered into the database. It has no affect on your already stored data.

In addition to this, R:BASE and Oterro, in any version, will correctly process all leap years if set properly. If the database is set to MM/DD/YY and you are either in a version prior to 5.5 or have your Century set to 19 and Year set to 0 in versions 5.5 and higher then processing 2/29/00 will be interprited as February 29th 1900 and will raise an error as 1900 was not a leap year. When set to Four Y's all versions should handle the 2000 leap year properly if you enter 2/29/2000.

The only exception to correct date processing is that R:BASE does not recognize the 10 days removed from the Gregorian calender circa 1582 when the calender shifted from Julian Dates to Gregorian Dates. This is mostly due to the fact that those 10 days were removed at different times in different countries. This will not, in most cases, affect your operations unless you are trying to determine the day of the week for dates prior to that time or the number of days between dates prior to the shift and dates after the shift.

As documented, all versions prior to 6.1A (Oterro version 1.1) will not return a valid Julian Date (JDATE) for dates which are beyond December 31st, 1999. The returned value may be either nonsense or a null. Julian Dates as used by R:BASE allow for the Year followed by the Numbers of Days from the beginning of the year. Versions prior to 6.1a return this in the YYDDD format while versions 6.1a and higher return this in the YYYYDDD format. This shift may require changes to code or to column widths. For example in versions 6.1 and lower the Julian Date for February 1st, 1999 is 99032. The year is 99 and February 1st is 32 days from the beginning of the year. Likewise December 31st 1999 will return 99365. In 6.1a and higher the two results would be 1999032 and 1999365. The Julian Date for December 31st, 2000 will be 2000366 (taking into account the Leap Day of this Leap Year).

It is a known bug that some versions of R:BASE will crash when trying to read a System Date greater than January 18th 2037 at 10:13pm. Others may load but may display a #DATE value of 1/1/4000 which is usually revealed to be 4000 BC when the Date Format is set to display the BC or AD (this can be done by setting the format to MM/DD/YYYY CC). The reason R:BASE chooses 4000 BC is that the minimum date R:BASE can hold is January 1st 3999 BC. This is day 1. Day 0 is the day right before that. Thus NULL dates or 0 dates will sometimes be displayed as 12/31/4000 BC or just 12/31/4000 (without the BC).

The following table outlines the type of compliance for R:BASE products released from 1982 to 2000. As a note, Windows, DOS and OS/2 of equal version numbers are considered to be the same version for Y2K compliance issues. If your specific version is not listed it may still be based on the same Database Engine as one of the versions listed below. For example Personal R:BASE version 1 was based on the same engine as R:BASE 3.1 and would fall into the same compliance categories. While Oterro is based on the same engine it is itemized seperately. Feel free to call us for more information.