Good Morning, Stewart -
About that message on 10-19-97 from Stewart Honsberger to Dave Hamilton:
 SH> -+- Quoting a message from Dave to Calixto Ong Ii -+-
 SH> -+- written 19 Oct 97  15:13:50 about WishList For Maximus 4 -+-
 COI>>         Century 1000 <--- 1900
 COI>>         Century 2000 <--- 2000+
 DH>> This is a good component of writing software that lasts longer than a
 DH>> thousand years, but suppose I have 'Century 2000' in my configs when
 DH>> the rollover happens. How will Max interpret existing files dated
 DH>> 02/25/97? Wouldn't it think it was 2097? There needs to be some
 DH>> cutoff line where dates higher than the specified number are
 DH>> considered to be from the previous century.
 SH> But then again, there are more problems you have to deal with, you'd
 SH> have to  set it for lower than 50 or so, but then again, there are
 SH> people who are born  pre-1950, so there's a problem, so you'd have to
 SH> set it for about 20 (I'm  pretty sure there aren't many 77 year old
 SH> modemers out there, but then again,  there likely are) So when it
 SH> gets to be 2020, you'd have to change it again,  so sysop's would end
 SH> up trying to remember to change the date ahead every  year.
First, I'm assuming that internal binary date handling has already
been taken care of. So a user's birthdate would be accurately 
represented. Y2k presents itself primarily on display and reporting,
changing report formats if you add an extra two digits, and breaking
just about everything that accesses logs.
If you have an internal arbitrary divider between current century
and past century, you can have it be an offset from current date so
that it is automatically maintained by the system once you decide
how many years it will be.
This is how many mainframe applications are dealing with it, with the
number of years for the divider mediated by the needs of the application.
Best,
  dave
daveh@sbase.com
--- FleetStreet 1.20+
---------------