|
On-Line Applications Research (OAR) Corporation has examined all of its products and internal processes to help insure that your investment in
our products and your trust in us as a supplier will not be affected by year 2000 related issues. It is our hope to supply you with quality services and products both in the year 2000 and beyond.
OAR's currently supported software products include RTEMS versions 4.x and higher. We have examined this product and are
confident that it's design and implementation will not be affected by year 2000 issues.
As with all software products, OAR cannot review and test discontinued products, prior releases, or modified versions of RTEMS.
All users of early versions of RTEMS are encouraged to upgrade if year 2000 issues are important to your mission. RTEMS can be freely obtained via the World Wide Web at www.rtems.com.
Additionally, OAR does not control other entity's hardware or software products that may be used in conjunction with RTEMS.
Therefore, OAR makes no statement as to the year 2000 compliance of such products or uses.
This does not constitute a warranty or extend the terms of any existing warranty. Please refer to licensing and copyright
information provided with RTEMS for warranty information. This information is provided for the sole purpose of assisting you in planning for the transition to the year 2000 and OAR assumes no liability for any
actions based on this document.
Technical Description
RTEMS supports multiple standards and each of these standards has its own epoch and time representation. These standards include both
programming API and programming language standards. In addition to the issues inside RTEMS itself, there is the complicating factor that the Board Support Package or application itself may interface with
hardware or software that has its own set of date/time representation issues. In conclusion, viewing date/time representation as "the Y2K problem" is very short-sighted. Date/time representation should
be viewed as a systems level issue for the system you are building. Each software and hardware component in the system, as well as the systems being connected to is a factor in the equation.
Hardware Issues
Numerous Real-Time Clock (RTC) controllers provide only a two-digit Binary Coded Decimal (BCD) representation for the current year.
Without software correction, these chips are a classic example of the Y2K problem. When the RTC rolls the year register over from 99 to 00, the device has no idea whether the year is 1900 or 2000. It is the
responsibility of the device driver to recognize this condition and correct for it. The most common technique used is to assume that all years prior to either the existence of the board or RTEMS are past 2000.
The starting year (epoch) for RTEMS is 1988.
Thus,
Using this technique, a RTC using a two-digit BCD representation of the current year will overflow on January 1, 2088.
RTEMS Specific Issues
Internally, RTEMS uses an unsigned thirty-two bit integer to represent the number of seconds since midnight January 1, 1988. This
counter will overflow on February 5, 2124.
The time/date services in the Classic API will overflow when the RTEMS internal date/time representation overflows.
The POSIX API uses the type time_t to represent the number of seconds since January 1, 1970. Many traditional UNIX systems as well
as RTEMS define time_t as a signed thirty-two bit integer. This representation overflows on January 18, 2038. The solution usually proposed is to define time_t as a sixty-four bit integer. This solution is
appropriate for UNIX workstations as many of them already support sixty-four bit integers natively. At this time, this imposes a burden on embedded systems that are still primarily using processors with native
integers of thirty-two bits or less.
Language Specific Issues
The Ada95 Language Reference Manual requires that the Ada.Calendar package support years through the year 2099. However, just as the
hardware is layered on top of hardware and may inherit its limits, the Ada tasking and run-time support is layered on top of an operating system. Thus, if the operating system or underlying hardware fail to
correctly report dates after 2099, then it is possible for the Ada.Calendar package to fail prior to 2099.
Date/Time Conclusion
Each embedded system could be impacted by a variety of date/time representation issues. Even whether a particular date/time
representation issue impacts a system is questionable. The date/time representation issues in POSIX do not impact a system using only the RTEMS Classic API. A system not using date/time at all is not impacted by
any of these issues. Also the planned end of life for a system may make these issues moot.
The following is a timeline of the date/time representation issues presented in this section:
- 2000 - Two BCD Digit Real-Time Clock Rollover
- 2038 - POSIX time_t Rollover
- 2088 - Correction for Two BCD Digit Real-Time Clock Rollover
- 2099 - Ada95 Ada.Calendar Rollover
- 2124 - RTEMS Internal Seconds Counter Rollover
|
