1 | @c |
---|
2 | @c COPYRIGHT (c) 1988-1999. |
---|
3 | @c On-Line Applications Research Corporation (OAR). |
---|
4 | @c All rights reserved. |
---|
5 | @c |
---|
6 | @c $Id$ |
---|
7 | @c |
---|
8 | |
---|
9 | @chapter Date/Time Issues in Systems Using RTEMS |
---|
10 | |
---|
11 | This section provides technical information regarding |
---|
12 | date/time representation issues and RTEMS. The Y2K problem has |
---|
13 | lead numerous people to ask these questions. The answer to |
---|
14 | these questions are actually more complicated than most |
---|
15 | people asking the question expect. RTEMS supports multiple |
---|
16 | standards and each of these standards has its own epoch and |
---|
17 | time representation. These standards include both programming |
---|
18 | API and programming language standards. |
---|
19 | |
---|
20 | In addition to the issues inside RTEMS |
---|
21 | itself, there is the complicating factor that the Board |
---|
22 | Support Package or application itself may interface with hardware |
---|
23 | or software that has its own set of date/time representation |
---|
24 | issues. |
---|
25 | |
---|
26 | In conclusion, viewing date/time representation as "the Y2K problem" |
---|
27 | is very short-sighted. Date/time representation should be viewed as |
---|
28 | a systems level issue for the system you are building. Each software |
---|
29 | and hardware component in the system as well as the systems being |
---|
30 | connected to is a factor in the equation. |
---|
31 | |
---|
32 | @section Hardware Issues |
---|
33 | |
---|
34 | Numerous Real-Time Clock (RTC) controllers provide only a two-digit |
---|
35 | Binary Coded Decimal (BCD) representation for the current year. Without |
---|
36 | software correction, these chips are a classic example of the Y2K problem. |
---|
37 | When the RTC rolls the year register over from 99 to 00, the device |
---|
38 | has no idea whether the year is 1900 or 2000. It is the responsibility |
---|
39 | of the device driver to recognize this condition and correct for it. |
---|
40 | The most common technique used is to assume that all years prior |
---|
41 | to either the existence of the board or RTEMS are past 2000. The |
---|
42 | starting year (epoch) for RTEMS is 1988. Thus, |
---|
43 | |
---|
44 | @itemize @bullet |
---|
45 | @item Chip year values 88-99 are interpreted as years 1988-1999. |
---|
46 | @item Chip year values 00-87 are interpreted as years 2000-2087. |
---|
47 | @end itemize |
---|
48 | |
---|
49 | Using this technique, a RTC using a |
---|
50 | two-digit BCD representation of the current year will overflow on |
---|
51 | January 1, 2088. |
---|
52 | |
---|
53 | @section RTEMS Specific Issues |
---|
54 | |
---|
55 | Internally, RTEMS uses an unsigned thirty-two bit integer to represent the |
---|
56 | number of seconds since midnight January 1, 1988. This counter will |
---|
57 | overflow on February 5, 2124. |
---|
58 | |
---|
59 | The time/date services in the Classic API will overflow when the |
---|
60 | RTEMS internal date/time representation overflows. |
---|
61 | |
---|
62 | The POSIX API uses the type @i{time_t} to represent the number of |
---|
63 | seconds since January 1, 1970. Many traditional UNIX systems as |
---|
64 | well as RTEMS define @i{time_t} as a signed thirty-two bit integer. |
---|
65 | This representation overflows on January 18, 2038. The solution |
---|
66 | usually proposed is to define @i{time_t} as a sixty-four bit |
---|
67 | integer. This solution is appropriate for for UNIX workstations |
---|
68 | as many of them already support sixty-four bit integers natively. |
---|
69 | At this time, this imposes a burden on embedded systems which are |
---|
70 | still primarily using processors with native integers of thirty-two |
---|
71 | bits or less. |
---|
72 | |
---|
73 | @section Language Specific Issues |
---|
74 | |
---|
75 | The Ada95 Language Reference Manual requires that the @i{Ada.Calendar} |
---|
76 | package support years through the year 2099. However, just as the |
---|
77 | hardware is layered on top of hardware and may inherit its limits, |
---|
78 | the Ada tasking and run-time support is layered on top of an operating |
---|
79 | system. Thus, if the operating system or underlying hardware fail |
---|
80 | to correctly report dates after 2099, then it is possible for the |
---|
81 | @i{Ada.Calendar} package to fail prior to 2099. |
---|
82 | |
---|
83 | @section Date/Time Conclusion |
---|
84 | |
---|
85 | Each embedded system could be impacted by a variety of date/time |
---|
86 | representation issues. Even whether a particular date/time |
---|
87 | repsentation issue impacts a system is questionable. A system |
---|
88 | using only the RTEMS Classic API is not impacted by the |
---|
89 | date/time representation issues in POSIX. A system not using |
---|
90 | date/time at all is not impacted by any of these issues. Also |
---|
91 | the planned end of life for a system may make these issues |
---|
92 | moot. |
---|
93 | |
---|
94 | The following is a timeline of the date/time representation |
---|
95 | issues presented in this section: |
---|
96 | |
---|
97 | @itemize @bullet |
---|
98 | |
---|
99 | @item 2000 - Two BCD Digit Real-Time Clock Rollover |
---|
100 | |
---|
101 | @item 2038 - POSIX @i{time_t} Rollover |
---|
102 | |
---|
103 | @item 2088 - Correction for Two BCD Digit Real-Time Clock Rollover |
---|
104 | |
---|
105 | @item 2099 - Ada95 @i{Ada.Calendar} Rollover |
---|
106 | |
---|
107 | @item 2124 - RTEMS Internal Seconds Counter Rollover |
---|
108 | |
---|
109 | @end itemize |
---|
110 | |
---|
111 | |
---|