====== Revelation Software and Year 2000 Compliance (Performance) ====== ====== ====== ==== Created at 06 MAY 1997 09:44AM ==== This paper is available in PDF below: [[http://www.revelation.com/o4wtrs/KB_Articles/KB0145_files/RevY2K.PDF|{{kb0145_1.png}} ]]   //Note: This document is provided only as a guide. Nobody takes responsibility for how you use this document. This information is provided only to serve as an outline of Year 2000 issues.// **The Year 2000 Problem** **What Is It?** When you receive your new credit card with an expiration date of  01, you know that means it will expire in the year 2001. Many computer systems, however, will assume that  01 means **19**01, and automatically generate overdue notices, for example. Other computer systems won t be able to accept the information at all, preventing any processing whatsoever. Obviously, this is a big problem. **How Did This Happen?** In the early years of computing, capacity (CPU cycles, memory, and disk space) was limited. Including the first two digits of a four-digit year required an extra two bytes each occurrence. At that point, the 1960s, the end of the 20th century was far enough in the future so as not to be an issue. Over the next two decades, CPU cycles improved but memory and disk space continued to be expensive. In the 1990s, these resources are no longer scarce, and longsighted programmers with  good  programming habits are using four-digits years to prevent this problem. Many programs and systems in use today, however, were implemented in the 1960s-1980s before the four-digit year was  affordable  and must be  retro-fitted  to allow for the four-digit year.   **Where Is the Problem?** Not only is the Year 2000 problem potentially very serious, it is also extremely complex because there are many places in which the problem can be lurking:         In various types of **software** including:         applications (line-of-business, functional)         vendor packages (productivity tools, operating systems, development tools, office suites, etc.)         data files         In various types of **hardware**, including:         information systems hardware (computers, printers, routers, peripherals, etc.)         non-information systems hardware (ATM machines, fax machines, elevators, satellites, etc.) To further compound the problem, there are many ways in which the Year 2000 problem can manifest itself. Below is a partial list of date-related problems:         Century ambiguity   this occurs when dates are represented with only two digits. This can cause a variety of problems including:         The rejection of any 20xx dates as invalid.         The inability to allow for the entry of four-digit years (user interface).         Incorrect sorting of a list of dates that include both 19xx and 20xx years.         Incorrect calculation of periods when the period spans the millenium rollover.         Extended semantics   some systems use interpret specific date entries differently; for example a date of  99  in an expiration date field might be used to represent  does not expire.          Calendar errors    systems that do not correctly account for leap years (including the year 2000) will incorrectly calculate the weekday (for example, after February 28, 2000).         Date overflow   some systems store dates as a base date/time plus an offset in days/seconds/etc. passed since that initial date. This  offset value  is represented in a fixed-length integer. After a period of time, the offset value will require an integer of greater length.         Inconsistent semantics   when two or more systems are interfaced, but the same-century assumptions made about two-digit years are different (for example 67-99 are interpreted as 1967-1999 but 00-66 are interpreted as 2000-2066), there will be problems.   **Revelation Software and the Year 2000** There are two major categories of Year 2000 issues pertaining to Revelation Software s suite of products:         Revelation Software products themselves         Applications developed **using** Revelation Software products The Year 2000 information pertaining to Revelation s product suite is divided into the following two categories:         Advanced Revelation and OpenInsight (all versions)         Revelation ViP **Advanced Revelation and OpenInsight (all versions)** The following information outlines Year 2000 issues pertaining to Advanced Revelation and OpenInsight in and of themselves. Advanced Revelation and OpenInsight are unique in that the **storage** of data is separate from the **display** of data. **Storage** Date values (including the date portion of date/time values) in Advanced Revelation and OpenInsight are stored as integer values, not as fixed length year, month, and day fields. The integer storage value is the number of days that have passed since the system's "zero date" (December 31, 1967); dates previous to the zero date are stored as negative integers. Storage of date values in Advanced Revelation and OpenInsight will not be a problem for another 5 million years. It is important to ensure that all dates are, in fact, stored in date format. If no format is specified for a date field, the data will be stored as a character string, and will not be treated as a date. For example, a properly defined date field will store the date 1/1/98 as the integer 10959 but if the field has not been defined as a date field, the data will be stored as the character string  1/1/98.  **Display** To avoid ambiguity when displaying date values, you should always use a four-digit year format. The default format, "D", uses the four-digit year, and four digits will always be displayed unless the number of digits is overridden; the "D2/" format, for example, displays the date in the format "dd/mm/yy", and is very popular in the United States. Using a four-digit year format, display of date values in Advanced Revelation andOpenInsight will not be a problem for another 8 thousand years. The data dictionaries define the defaults for data input/output display.  Multiple dictionary items can be created for the same piece of data to provide multiple display formats.  Because the dictionary item is separate from the storage of the data, the format can be changed without affecting the data itself. Forms, reports and programs will default to the date display format defined in the data dictionary; however they may also override this default. To ensure Year 2000 compliance, all date fields in the dictionary should be changed to a D4 format. Then any forms, reports, or programs that override dictionary defaults should be checked to ensure they, too, are in D4 format. **Data Entry** Most dates are entered with either no year or with a two-digit year. Dates entered without a year default to the current year. Dates entered with a two-digit year are subject to the following rule: For year values between 0 and 29 inclusive, the year is assumed to be after 2000, and for years between 30 and 99 inclusive, the year is assumed to be prior to 2000. This assumption is meant to assist in data entry during the years when dates being entered are from either the twentieth or twenty-first centuries. It is recommended that date display be changed to the D4 (four-digit) format and input mask and validation be place on the field to require four-digit year input, to prevent user error. It is also possible to write a program that will cause dates entered with a two-digit year to default differently than currently defined. You need to make sure that the first two digits of a four-digit year have not been hard-coded in your application. Advanced Revelation and OpenInsight also correctly accounts for leap years, including the rule exceptions for leap centuries and every fourth leap century.   |Display (implement); can also override dictionary-defined default\\ \\ [
]\\ \\ Display (define default)\\ \\ [
]\\ \\ Storage|{{kb0145_2.png}}|3. Ensure any overrides are D4 (4 digit) year format\\ \\ [
]\\ \\ 2. Ensure date input/output is D4 (4 digit) year format\\ \\ [
]\\ \\ 1. Ensure dates stored as dates (not character strings)\\ \\  |   Applications **developed using** Advanced Revelation or OpenInsight may include Year 2000 problems not outlined above. The table in **Appendix 1 **is provided as a guideline to help application developers, application users, and vendors to identify potential Year 2000 problems. Note: this table is not intended to be an exhaustive list of potential problem areas. **Revelation ViP (all versions)** Revelation ViP applications are used to access the data stored on Notes and relational databases. As such, it complies with Year 2000 requirements to the extent that the database itself complies. Specifically, any date/time values formatted in the ViP data object as long date format will always display and update correctly - that is as the data source has stored the date/time information. Any date/time values formatted in the ViP data object will also render properly, with DD/MM/49 and below treated as 2049 and below, and DD/MM/50+ treated as 1950 and above. This is the same approach as Notes. Note that for formatting date/time values, the combination of the LotusScript Format$ function and ViP's CellGetString method is the most predictable means of formatting date/time results. CellGetString method returns a text string of full canonical form:YYYYMMDDHHMMSShh.   Applications **developed using** Revelation ViP may include Year 2000 problems not outlined above. The table in **Appendix 2** is provided as a guideline to help application developer, application users, and vendors to identify potential Year 2000 problems. Note: this table is not intended to be an exhaustive list of potential problem areas. **Where Can I Get Help?** If you need technical assistance in assessing Year 2000 compliance with Revelation-based products, Revelation Software has a community of consultants and solution providers that can help you. These partners are listed on Revelation s [[notes:///8525660500671F81/E4A32622500660198525631900091149/E2552236FE02EE0985256620004A095F|Developer Network]] section.   There are also a whole host of legal issues surrounding Year 2000 compliance. You are advised to consult with your own legal counsel in all legal matters.   The are great many resources to provide you more information about the technical and legal issues surrounding the Year 2000 problem. In fact, there are a variety of hyperlink clearinghouses pertaining to the subject on the Web, including the  Year 2000 Information Center  at http:%%//%%www.year2000.com.   **Appendix 1: Advanced Revelation, OpenInsight and Year 2000 issues** //Note: this table is not intended to be an exhaustive list of potential problem areas.// // // |**Type of problem** |**Manifestation of problem** |**Advanced Revelation andOpenInsight (all versions)** |**Applications developed with Advanced Revelation andOpenInsight (all versions)** | |Century ambiguity |The rejection of any 20xx dates as invalid |Because Advanced Revelation andOpenInsight use an integer to store dates as an  offset value  (positive and negative), they will not reject any dates as invalid.|Ensure there is no application logic that rejects dates. | |  |The inability to allow for the entry of four-digit years (user interface |Advanced Revelation andOpenInsight allow for the entry of four-digit years. |If the user interface currently allows only for two-digit year input, it can be changed without corruption to enable four-digit year input. | |  |Sorting of a list of dates that include both 19xx and 20xx years |Because Advanced Revelation andOpenInsight store dates as an integer, years will be correctly sorted. |Ensure that all date values are stored in date format and that all dates are right-justified. | |  |Incorrect calculation of periods when the period spans themillenium rollover|Because Advanced Revelation andOpenInsight store dates as an integer, periods will be correctly calculated. |Ensure that all date values are stored in date format and that all dates are right-justified. | |Extended semantics |Specific values for date fields reserved for special interpretation |No specific values are reserved for special interpretation. |Ensure there are no programs that reserve any date values for special interpretation. | |Calendar errors |Incorrect accounting for leap years |Advanced Revelation andOpenInsight correctly account for leap years. |Ensure that all date values are stored in date format. | |Date overflow |Fixed-length integer not sufficient to represent the date |Date overflow will not be a problem for another 5 million years |not applicable | |Inconsistent semantics|Interface of multiple systems that make different same-year assumptions |For year values between 0 and 29 inclusive, the year is assumed to be 2000-2029, and for years between 30 and 99 inclusive, the year is assumed to 1930-1999. |Ensure that any other interfacing systems assume values between 0 and 29 to be 2000-2029, and years between 30 and 99 to be 1930-1999. If this is not the case, a four-digit year must be used.|   **Appendix 2: Revelation ViP and Year 2000 issues** //Note: this table is not intended to be an exhaustive list of potential problem areas.// // // |**Type of problem** |**Manifestation of problem** |**Revelation ViP (all versions)** |**Applications developed with Revelation ViP (all versions)** | |Century ambiguity |The rejection of any 20xx dates as invalid |The ViP Data Object interprets year values between 0 and 49 to bee2000-2049, and values between 50 and 99 to be 1950-1959. For all years, ViP allows the entry of four-digit years.|Instruct users to enter four-digit years for any date before 1950 or after 2049. If the user interface only allows the input of two-digit years, amend the UI to allow entry of four-digit years. | |  |The inability to allow for the entry of four-digit years (user interface |Revelation ViP allows for the entry of four-digit years. |If the user interface currently allows only for two-digit year input, it must be changed to enable four-digit year input. | |  |Sorting of a list of dates that include both 19xx and 20xx years |ViP correctly sorts dates stored with a datatype of Date/Time. |Compliance may depend on specific ODBC drivers and data sources. Ensure that the developer is not using dates stored as text, unless text format is sortable. | |  |Incorrect calculation of periods when the period spans themillenium rollover|ViP correctly calculates time intervals. |Compliance may depend on compliance of your data source. | |Extended semantics |Specific values for date fields reserved for special interpretation |ViP reserves the date 12/30/1899 as a "NO DATE, TIME ONLY" tag for Notes databases. |Compliance may depend on compliance of your data source.\\ \\ Developers using Notes data sources may need to use this reserved date to interpret time-only data (that is data that is being or was input as time without a date.)| |Calendar errors |Incorrect accounting for leap years |ViP correctly accounts for leap years. |Compliance may depend on compliance of your data source. | |Date overflow |Fixed-length integer not sufficient to represent the date |ViP does not support integer representation of a date.  A floating point representation is available, and supports all dates and times. (date 0.0 is 12/30/1899). |Compliance may depend on compliance of your data source if date is out of range of an ODBC accessed database. | |Inconsistent semantics|Interface of multiple systems that make different same-year assumptions |For year values between 0 and 49 inclusive, the year is assumed to be 2000-2049, and for years between 50 and 99 inclusive, the year is assumed to be 1950-1999. |Ensure that any inter-facing systems assume values between 0 and 49 to be 2000-2049, and years between 50 and 99 to be prior to 1950-1999. If this is not the case, a four-digit year must be used. |   See also [[notes:///85256290006E71FC/E4A32622500660198525631900091149/F949F7B926FFC5828525665700774213|Revelation's Year 2000 Readiness Disclosure]]