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