Text 1950, 111 rader
Skriven 2007-03-09 11:56:03 av mark lewis (1:3634/12.0)
     Kommentar till en text av JEAN PARROT (1:123/140)
Ärende: 2038 ?
==============

 ML> that's 2038 and it will happen to _all_ programs that use that time
 ML> library and don't get updated...

 JP> Is this something alike the Y2K glitch ? What is there magic in 
 JP> 2038 as a number ? Is it related to a binary code ? 

the y2k problem was one of "difference"... for example, using only the last two
digits of the year, you can easily sort 96, 97, 98, and 99... however, they
won't sort properly once you "restart" at zero... since zero is less then nine,
it will come _before_ 9 and not after...

then there was also math... using the last two digits, 99-98 give 1 year,
however, 00-99 does not...

the 2038 problem stems from the storage and calculation of the current time by
counting the _seconds_ since the "EPOCH"...

===========================================================================
epoch
   
DEFINITION - In a computing context, an epoch is the date and time relative to
which a computer's clock and timestamp values are determined. The epoch
traditionally corresponds to 0 hours, 0 minutes, and 0 seconds (00:00:00)
Coordinated Universal Time (UTC) on a specific date, which varies from system
to system. Most versions of Unix, for example, use January 1, 1970 as the epoch
date; Windows uses January 1, 1601; Macintosh systems use January 1, 1904, and
Digital Equipment Corporation's Virtual Memory System (VMS) uses November 17,
1858.

The date and time in a computer is determined according to the number of
seconds or clock ticks that have elapsed since the defined epoch for that
computer or platform. This number is limited by the word length, and also by
the number of clock ticks per second. In a 32-bit computer with 1 tick per
second, for example, the clock will wrap around (that is, reach its maximum
numerical time) on January 18, 2038. This is not likely to be a problem,
because most computers are obsolete after a few years, and longer word lengths
and/or new epochs will likely be defined before 2038. However, in a computer
with 16 ticks per second, wrap-around can occur well within the useful lifetime
of the machine.
===========================================================================

so, basically, since existing code uses a *signed* longint, (signed meaning it
can be positive and negative), we only get half the full range... here's a
chart explaining a bit more so that you can see the ranges... 

===========================================================================
  Ü Integer types
  ßßßßßßßßßßßßßßßß
 Turbo Pascal provides five predefined Integer
 types. Each type denotes a specific subset of
 the whole numbers, as shown here:

    Type    ³          Range         ³  Size
  ÍÍÍÍÍÍÍÍÍÍØÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍØÍÍÍÍÍÍÍÍ
   Shortint ³       -128..127        ³  8-bit
   Integer  ³     -32768..32767      ³ 16-bit
   Longint  ³-2147483648..2147483647 ³ 32-bit
   Byte     ³          0..255        ³  8-bit
   Word     ³          0..65535      ³ 16-bit

 All Integer types are ordinal types.
===========================================================================

soooo... we can only count from 0-2147483647 for the number of seconds we can
store... 0 being the epoch which, IIRC, for DOS was also Jan 1, 1970 like the
UNIX reference above...

2147483647.0000 /  60    = 35791394.1167 minutes
  35791394.1167 /  60    = 596523.2353 hours
    596523.2353 /  24    = 24855.1348 days
     24855.1348 / 365.25 = 68.0497 years

1970 + 68 = 2038
365.25 * .0497 = 18 days

so we see failure/rollover 18 days into the year 2038... oh, yes... i did round
the above figures to 4 decimal places ;)

this can be easily handled by switching to using unsigned longints which would
double the time without changing the epoch... however, we can also change the
epoch... the gregorian calendar, which we all use, loops around every 28
years... thus, Jan 1st 1970 and Jan 1st 1998 were both on the same day and all
follows thru exactly overlaying the calandar chart... since we are considering
the start of the epoch and the start of the "calendar loop" to be the same, we
can more easily adjust the epoch instead of increasing the size of the
counter...

however, both methods of fixing this problem are met with the exact same
situation of code and that being how to get the changes into existing
applications and code libraries... many libraries are hard coded to subtract
1970 from the year result where, in fact, they should be coded to subtract the
starting year of the current epoch...

so, no matter, really, what we come up with, there's no real way to fix the
problem in existing applications without coming up with a patch for one or the
other and get that patch spread and applied to everything out there... this is
also complicated by the "exe compression" and the "self protection" stuff that
is also added to programs... 

 JP> It is not that important to me, Nancy has calculated that I would 
 JP> be 103 by then, if I survive. Actually, for Nancy, I would be 
 JP> 106.

don't count yourself short... as long as the senses remain intact and you have
a way of interfacing with the computer, you can still putter along with the
rest of us O:)

)\/(ark

 * Origin:  (1:3634/12)