Kronos terminals and software deal primarily with dates within a narrow window of time, generally the past, current, and future pay periods. Thus two-digit years are not ambiguous in context. Our techniques for interpreting two-digit dates were designed into our products at their inception.

The internal representation used to store, process, and communicate dates in these products is such that nothing special happens at the transition from December 31, 1999 to January 1, 2000.

Performing formal scripted tests is part of Kronos's commitment to a rigorous testing program. In fact, limited testing into the year 2000 was performed on certain versions of TKC DOS at the time of their initial release. Consult "Table 1: Products that have been or will be tested", page 5, for the exact version numbers that have been tested and passed, and the versions that will be tested in the future.

In addition, since some users are requesting that software make use of exclusively four-digit year fields in all dates, Kronos has brought the latest versions of its TKC/S and TKCWin products (with ancillaries) up to full Four-digit Year 2000 Compliance.

Addressing our products is only one part of our Year 2000 effort. Kronos has established an executive level steering committee to address Year 2000 issues that could affect the company, its internal systems, its products, and its services. This committee has representatives from relevant company departments. Comprehensive plans have been developed to ensure that we continue to effectively serve our customers into the next century.

--- By design: Since 1979, our products have used a binary internal date format which operates correctly in both the 20th and 21st centuries.

--- By testing: Carefully designed test scripts are being run, in which our products are operated while the system date is advanced, to test operation crossing into, and in, the 21st century.

--- By code inspection: Where appropriate, using selected software tools, programmers are inspecting our programs to further evaluate Year 2000 Compliance.

"Year 2000 Compliant" means that the Product will continue, crossing into the year 2000 and beyond, to perform all date related arithmetic and logical operations correctly, including operations which cross the century boundary, to sort date-related information in correct chronological order, to correctly recognize the year 2000 as a "leap-year", and to store internal, date-related information (including all interim date-related results) in a manner that is unambiguous as to century.

In other words, Kronos products shown as "Year 2000 compliant" in the tables will continue to operate in and beyond the year 2000 as they operated when the system was purchased.

"Four-digit Year 2000 Compliant" applies to Kronos products that are "Year 2000 Compliant" according to the above definition, and which can utilize only four-digit year fields in User Interface, import, export, and report formats. The only two-digit year fields used in "Four-digit Year 2000 Compliant" products are if the user specifically selects two-digit date formats in the Windows "Settings", and for backward compatibility purposes in import/export formats.

Note that Kronos is not responsible for failures attributable to other products (e.g. the operating system, or other software, firmware, or hardware) used with Kronos products, or if the Kronos product is not used in accordance with Kronos specifications and/or documentation. In addition, nothing on this web page constitutes a warranty or extends the term of any existing warranty. Customers should refer to their Kronos Sales Agreement and Software License or the Kronos Software License Agreement, as applicable, for their warranty.

For further notes on the compliance definitions, see "Notes on the Compliance Definitions", page 4.

For a list of the actual product version numbers that are being tested for Year 2000 Compliance, see "Table 1: Products that have been or will be tested", page 5.

Internal design: Date storage, date arithmetic, and data communications:

All Kronos's standard DOS, Unix, and Open VMS versions of TKC, TKCWin, and all 100, 400 and 500 series Kronos terminals use a common method for their internal date storage and arithmetic, and for the communications of dates between the terminals and TKC. These products use an "offset Julian" date, defined as the number of days elapsed since January 1, 1985. This design characteristic should allow them to:

" Operate correctly in both the 20th and 21st centuries.

--- Perform all date-related arithmetic and logical operations correctly, including operations which cross the century boundary.

--- Sort date-related information in correct chronological order.

--- Correctly recognize the year 2000 as a leap-year.

--- Store and communicate internal, date-related information in a manner that is unambiguous as to century.

Thus, these products have no century ambiguity in their data communications formats, and in their internal storage and manipulation of data. Crossing from December 31, 1999 to January 1, 2000, this internal representation merely increments from 5477 to 5478; in other words, nothing special happens.

The above design philosophy has been in use continuously since our first printing timeclock was shipped in November of 1979, although the reference point has since been altered (early clocks stored the time of day and the date together, as the number of minutes elapsed since January 1, 1900, a 32-bit quantity). As a result, we believe that the introduction of year 2000 failures in our arithmetic date calculations is quite unlikely.

External interfaces: The user interface, reports, and import/export

Externally, in the User Interface, on reports, and in Import/Export, different Kronos DOS and Unix versions of TKC, TKCWin, TKC/S, and 400 and 500 series Kronos terminals deal with dates in different ways. Older products use two-digit years in dates, for example, while newer products allow the use of four-digit years.

Where dates with two-digit year fields are used, these dates are unambiguous in context. This is because Kronos products only deal with dates that are a limited distance in the past or in the future. In these products, a "windowing" technique is used to remove date ambiguity: all two-digit dates can be interpreted as belonging to a 100-year "window" of time. In some products, this is a fixed "window", running from 1985 through 2084; in others, it is relative to the current date. These "windows" were designed into the product from the beginning; they were not added later to fix Year 2000 problems. Again, it is important to note that in normal operation, Kronos products deal only with dates in a narrow range. These products thus indicate the century implicitly, although not explicitly.

Kronos is committed to a rigorous testing program to determine whether its products are Year 2000 Compliant.

Some informal initial testing was done in July of 1997 on many of our most widely-used products: TKCWin, DOS versions of TKC, KSM, KAP, CardSaver, and Poster, and terminals from the 400 series. In this informal testing, trained Software Quality Assurance personnel familiar with each product advanced the system time across and into the 21st century, and verified basic system operation. This initial testing verified the basic operation of these products crossing into the year 2000 and beyond.

To verify our initial results, and to widen our testing to include other products, the initial testing is being followed by the execution of more formally designed test plans focused on Year 2000 Compliance. Many of the tests are being automated, so that they can be carried out from this point forward on all future product releases, to assure that year 2000 bugs do not slip into our code in the course of fixing other bugs or adding product features. Our general testing philosophy is to actually advance the time on the system under test, which in software systems means advancing the time on the computer that the software is running on. We do not depend upon mechanisms for "simulating" the advance of time; actual operating system dates are changed. Our products are operated in pay periods set to the end of 1999, crossing from 1999 into the year 2000, and completely inside the year 2000 (including February 29, 2000).

For a list of the actual product version numbers that are being tested for Year 2000 Compliance, see "Table 1: Products that have been or will be tested", page 5.

Our testing is mostly "black box" testing, in that it verifies the proper operation of our products in ways that are independent of knowledge of how the product operates internally. Code inspection is also used, where Kronos deems it appropriate. Code inspection can identify portions of the code that might need to be further studied, or specifically exercised by test scripts.

To cite one example: we know that areas that have greater complexity on the level of external (month, day, year) date formats are where problems, if any, are more likely to show up. Hence, we have added specific tests of Daylight Savings Time functionality to our TKC testing. It is harder to find problem areas in our internal processing of dates, where simple integer arithmetic is done with "offset Julian" dates.

For a list of the actual product version numbers that are being tested for Year 2000 Compliance, see "Table 1: Products that have been or will be tested", below.

Kronos terminals and related software, in use, deal primarily with dates within a narrow window of time, generally a particular pay period, and one pay period in the past, and one in the future. It is thus quite reasonable for such software to utilize dates containing two-digit years, since a two-digit year is not generally ambiguous in the context of the product. This is why we have defined "Year 2000 Compliant" so as to not require the use of four-digit date fields, and have created a separate definition of "Four-digit Year 2000 Compliant". Modules which deal with dates outside of a narrow window, such as the Kronos Archive Program, make explicit provisions for handling a wider date range.

With the widespread awareness of potential problems with the advent of the 21st century, however, has come a broad push for programs to make use of exclusively four-digit year fields in all dates, to eliminate any ambiguity. Kronos has therefore brought the latest versions of its TKC/S and TKCWin code (with ancillaries) up to full Four-digit Year 2000 Compliance. Our character mode products, however, will not be made Four-digit Year 2000 Compliant, given that they will continue to operate in and beyond the year 2000 as they operated when the system was purchased.

Note that Kronos is not responsible for failures if the computer or Operating System on which its software resides does not provide correct date information, or for failures attributable to the software, firmware, or hardware of others. In particular, many PCs that are still in use will suffer Real-Time Clock failures at the turn of the century. In some, the BIOS ("Basic Input/Output System", in ROM) and/or the Operating System will not cross the century boundary correctly. These failures may not be manifest until the computer is rebooted sometime after the century change. In some cases, all that will be required will be to reboot the system, and manually reset the Real-Time Clock. In other cases, an Operating System upgrade, or even a BIOS change, will be required. Kronos software products obtain the current date and time from the computer they reside on, and it is the responsibility of our end users to ascertain that the computer is providing the correct date. The information in this paragraph is provided with the understanding that Kronos is not engaged in rendering professional service or advice on computer systems, and Kronos does not warrant the completeness or accuracy of its contents. If you require expert assistance and information regarding your computer system you should contact your computer system provider.

The products in Table 1 have been or will shortly be formally tested for year 2000 compliance. Note that:

"Testing" refers to the execution of formal, scripted tests. Many of these tests are being automated, so that they can be re-run as regression tests on subsequent versions. Testing is also being applied to selected older product revisions that are in widespread use.

Since Kronos has been shipping products for nearly 19 years, we do not plan to test every single version of every product we have shipped. Therefore, to be assured of having a product that has been tested as being "Year 2000 Compliant", users may wish to upgrade to one of the product versions shown as tested in column 4 of Table 1.

Kronos reserves the right to conduct further tests at any time, and cannot rule out the possibility that this additional testing will reveal problems not originally detected.

Kronos has tested and intends to test only its standard products, not its custom products. This table will be updated as various products pass Year 2000 testing.

"TKC" is an abbreviation for "Timekeeper Central" software. The "Ancillaries" for Timekeeper Central are the Kronos Archive Program ("KAP"), the Kronos Scheduling Module ("KSM"), Cardsaver , Accruals, Poster, and Messaging. The listing of a standard product version in this table implies that later standard product versions will be Year 2000 tested before their release. Concerning whether versions are "Four-digit Year 2000 Compliant", the versions to be tested are listed in brackets in column 3 of the table, and the results of those tests are listed in brackets in column 4.

DOS products are being tested only for dates extending out into the first decade of the 21st century. TKC/S and TKCWin are being tested a greater distance into the future. This is why we have moved the end date specification from the compliance definitions into the table.

The following product versions are obsolete, and will not be tested.

Note 1: TKC/S 2A.02 has passed its testing as "Year 2000 Compliant" through 2084. Users needing a version that is "Four-digit Year 2000 Compliant" should upgrade to TKC/S 2A.03. Version 2A.02 is not "Four digit Year 2000 Compliant" due to a small number of residual 2-digit year fields which show even with 4-digit "Regional Settings". These include the title bar of the Timecard window pane in the Timecard Editor, and specified dates and date ranges on reports (although the "date printed" on the report shows as four-digits). In addition, on some displayed reports, the last digit of four-digit years is slightly clipped, but still readable (there is no problem on the printed version of the same report).

Note 2: TKCWin versions 2C.03.09 and 2C.02.07 have passed their testing as "Year 2000 Compliant" through 2035, when operated with the Windows "Regional Settings" set to use a "short date" format containing a four-digit year (either "M/d/yyyy" or "MM/dd/yyyy"). These versions are not "Year 2000 Compliant" if any other "short date" format is used. Four-digit "Regional Settings" are generally recommended for operation around the turn of the century, and Kronos also recommends that users be instructed to always enter full four-digit years in dates during that period, to avoid confusion. If a two-digit date is entered as a shortcut in TKCWin 2C, the century is taken as the current century at the time the date is entered.

Note 3: It is currently our intent to fix the problem in the terminal's next maintenance release. The problem is with the software in the terminal; there is no known problem with the terminal hardware. When an update is available, the user will be able to update the terminal software by uploading from a PC.

Note 4: The "400 series" of terminals includes all terminals numbered "4xx", where "xx" is any two-digit number. The number may also be followed by one or more letters, and additional information (type of card read, memory size, and so on). The "100 series" is similarly numbered, "1xx".

Note 5: TKC/S gets the current date and time from both the "Client" computer and, via ODBC, from the open database. Kronos is not responsible for failures if the client computer or its operating system or the database do not provide correct date and time information. During testing, the date was advanced on both the client and the server, to simulate realistic operating conditions.

Note 6: The version number "6B.01" completely specifies this product. The system of "maintenance releases" (sometimes called "X-Revs") was not yet in use at the time of version 6B.

Note 7: It is our intent to complete the scripted testing TKC DOS version 8iD by the end of January, 1999.

Note 8: Note on a compliance exception in the ShopTrac products: Version 3.1.01 of the listed modules passed their testing as noted through 2030 if all dates are entered with four-digit years. If two-digit shortcut entries are used, there is a problem with entry of the date "01/01/00", typed as shown with a two-digit year. This entry will not be accepted as a valid date. The date "01/01/2000" can be successfully entered, if it is typed as shown with a four-digit year. The entry of January 1, 2000 using a two-digit year "00" will not be accepted regardless of what the current date is at the time the entry is made. That is, the problem is with the date being entered, not with the date it is being entered on. "01/01/00" is the only date that exhibits this problem. This problem had not been reported when our test results were initially published.

Note 9: It is currently our intent to revise version 2.0 so that it will pass. There are currently no plans to fix version 1.0LA.

Note 10: SCO Unix 8D.08.15 and 8D.08.15 French were built and tested on version 5.0.4 of the operating system.

Note 11: NCR 3000 Unix version 8D.07.15 was built and tested on version 3.00 of the operating system, which is not itself certified as a Y2K compliant version. It is currently still our intent to test versions 8D.08 and 8DH.08 on a compliant version of the NCR-3000 operating system.

Note 12: AIX Unix 8D.08.15 and 8D.08.15 French were built and tested on version 4.3.1 of the operating system.

Note 13: DG-UX Unix version 8D.07.15 was built and tested on version 3.10MU04 of the operating system, which is not itself certified as a Y2K compliant version. It is currently still our intent to test versions 8D.08 and 8DH.08 on version 4.11MU01 of the DG-UX operating system.

Note 14: HP-UX Unix 8D.08.15 and 8D.08.15 French were built and tested on version 10.2 of the operating system.