source: rtems/doc/FAQ/endoftime.t @ f6b0196
Last change on this file since f6b0196 was f6b0196, checked in by Joel Sherrill <joel.sherrill@…>, on 11/24/99 at 18:22:33

Added information on RTEMS Time/Date? Representatin.

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