path: root/doc/FAQ/endoftime.texi
diff options
authorRalf Corsepius <>2004-07-31 03:27:44 +0000
committerRalf Corsepius <>2004-07-31 03:27:44 +0000
commit2af46634a33fcd9aa89444f7279e80bdd86f862e (patch)
tree5d62c74cbb13e8fa9d5fc649e1afb7f22e884df5 /doc/FAQ/endoftime.texi
parentec95bd843845658c41c33b0444c5d6d25e3067e8 (diff)
2004-07-31 Ralf Corsepius <>
* FAQ/basic.texi, FAQ/bsp.texi, FAQ/build45.texi, FAQ/concepts.texi, FAQ/debug.texi, FAQ/endoftime.texi, FAQ/freesw.texi, FAQ/hwdebugaids.texi, FAQ/projects.texi, FAQ/tools.texi, FAQ/version.texi: New.
Diffstat (limited to 'doc/FAQ/endoftime.texi')
1 files changed, 135 insertions, 0 deletions
diff --git a/doc/FAQ/endoftime.texi b/doc/FAQ/endoftime.texi
new file mode 100644
index 0000000000..4664235baf
--- /dev/null
+++ b/doc/FAQ/endoftime.texi
@@ -0,0 +1,135 @@
+@c COPYRIGHT (c) 1988-2002.
+@c On-Line Applications Research Corporation (OAR).
+@c All rights reserved.
+@c $Id$
+@node Date/Time Issues in Systems Using RTEMS, Hardware Issues, , Top
+@chapter Date/Time Issues in Systems Using RTEMS
+* Hardware Issues::
+* RTEMS Specific Issues::
+* Language Specific Issues::
+* Date/Time Conclusion::
+@end menu
+@end ifinfo
+This section provides technical information regarding
+date/time representation issues and RTEMS. The Y2K problem has
+lead numerous people to ask these questions. The answer to
+these questions are actually more complicated than most
+people asking the question expect. 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
+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.
+@node Hardware Issues, RTEMS Specific Issues, Date/Time Issues in Systems Using RTEMS, Date/Time Issues in Systems Using RTEMS
+@section 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,
+@itemize @bullet
+@item Chip year values 88-99 are interpreted as years 1988-2002.
+@item Chip year values 00-87 are interpreted as years 2000-2087.
+@end itemize
+Using this technique, a RTC using a
+two-digit BCD representation of the current year will overflow on
+January 1, 2088.
+@node RTEMS Specific Issues, Language Specific Issues, Hardware Issues, Date/Time Issues in Systems Using RTEMS
+@section 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 @i{time_t} to represent the number of
+seconds since January 1, 1970. Many traditional UNIX systems as
+well as RTEMS define @i{time_t} as a signed thirty-two bit integer.
+This representation overflows on January 18, 2038. The solution
+usually proposed is to define @i{time_t} as a sixty-four bit
+integer. This solution is appropriate for for UNIX workstations
+as many of them already support sixty-four bit integers natively.
+At this time, this imposes a burden on embedded systems which are
+still primarily using processors with native integers of thirty-two
+bits or less.
+@node Language Specific Issues, Date/Time Conclusion, RTEMS Specific Issues, Date/Time Issues in Systems Using RTEMS
+@section Language Specific Issues
+The Ada95 Language Reference Manual requires that the @i{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
+@i{Ada.Calendar} package to fail prior to 2099.
+@node Date/Time Conclusion, , Language Specific Issues, Date/Time Issues in Systems Using RTEMS
+@section 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. A system
+using only the RTEMS Classic API is not impacted by the
+date/time representation issues in POSIX. 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
+The following is a timeline of the date/time representation
+issues presented in this section:
+@itemize @bullet
+@item 2000 - Two BCD Digit Real-Time Clock Rollover
+@item 2038 - POSIX @i{time_t} Rollover
+@item 2088 - Correction for Two BCD Digit Real-Time Clock Rollover
+@item 2099 - Ada95 @i{Ada.Calendar} Rollover
+@item 2124 - RTEMS Internal Seconds Counter Rollover
+@end itemize