NB> It certainly isn't because I would like it to, because I'm still using
 NB> pretty much pure DOS.  But, I've been told by my Wizard that in 2108
 NB> the FAT file system on which DOS is based will cease to function. 

 JP>         Maybe you can ask Richard, I do not think that this would
 JP> be    like a Y2K bug. It is just, methinks, that the way the new
 JP> CPUs are    designed. After all, a programmer has to talk the CPU's
 JP> language    although through ML or via an assembler, and the new
 JP> ones are quite    different from a design point of view. Strickly
 JP> above my head.      

it is strictly a roll-over problem... i know i've posted this chart before
but i'll do it again as it was several years ago...

  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

the values for time and date are stored as the number of seconds since the
epoch... for some languages, that epoch is 1970... others have a different
epoch that may be older or newer...

in any case, the largest counter available is the Longint which can only
count as high as 2147483647... once it reaches that number, the next one is
-2147483648 which is what breaks everything...

quite a simple problem, actually... the fix, on the other hand, is a real bugger...

)\/(ark