From e05f675f71efeaaad0ee60449537ef03de630885 Mon Sep 17 00:00:00 2001 From: Ralf Corsepius Date: Fri, 9 Sep 2005 11:45:24 +0000 Subject: Remove --- doc/FAQ/endoftime.texi | 135 ------------------------------------------------- 1 file changed, 135 deletions(-) delete mode 100644 doc/FAQ/endoftime.texi (limited to 'doc/FAQ') diff --git a/doc/FAQ/endoftime.texi b/doc/FAQ/endoftime.texi deleted file mode 100644 index 4664235baf..0000000000 --- a/doc/FAQ/endoftime.texi +++ /dev/null @@ -1,135 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - - -@node Date/Time Issues in Systems Using RTEMS, Hardware Issues, , Top - -@chapter Date/Time Issues in Systems Using RTEMS -@ifinfo -@menu -* 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 -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. - - -@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 -moot. - -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 - - - -- cgit v1.2.3