> If you don't want to change the hardware, you can do a technique called "windowing", where you have a pivot year, like, say "1930", and if the year number is "29" then it assumes that it means "2029" and if it is "30" then it assumes "1930". Of course, if the wrong 2-digits get interpreted, then you may have a reference to Line #1930, or maybe an increase to 1930% interest...

A worse problem, you can only refer to a hundred
distinct years.

> Other alternatives include changing the date format itself to 4-digits (good until the year 10k), or changing to hex or something like that (which does the Y2K thing in 2042 or some funky date like that).

You're talking about two different things here.
(Both ultimately end up with the same basic problem,
though.) One is a problem representing a year
only, where only two digits are used. This is
either done in the user interface part (where the
user is not permitted to enter more than two) or
in ASCII representation, where the year is stored
in the actual physical characters that represent
the year. The solution to both is to allow the
entering and storing of more than two digits, be
it four or five or ten or whatever.

The Y2037 problem is when the rollover occurs when
the entire date (not just the year) in binary
notation, which is how computers ultimately store
everything. On UNIX mainframes, the date is stored
as the number of seconds which have elapsed since
January 1, 1970. This was simply an arbitrary
choice made by the programmers of UNIX, who,
frankly, didn't think UNIX would be used seriously
*at*all*, let alone by sometime in the year 2037,
which is when the number of seconds you need to
store the date exceed the number of *binary*
digits allocated for the date by the operating
system. Fortunately, this is easy to fix. You
change the size of the integer used to store the
date from 16 bits to 32 bits, and presto, you can
store any date between January 1, 1970, and I
don't know how many millions of years in the future.
Then you recompile the operating system, and you're
all set. All Sun has to do sometime between now
and then is change that one declaration and release
it in their next version of SunOS. Same with all
the others.

> All of the "fixes" merely delay the problem- maybe they delay it 30 years, maybe 42, maybe 100 or 1000 or 10,000, but there is no "cure" to the problem.

Sure there is. Ignoring for the moment the fact
that a very small amount of memory can still
store values in the trillions (and who cares if
there's a Y2Trillion problem?) you don't have to
program a fixed memory size to store the date.
By using dynamic data structures (i.e., you
allocate as much memory as you need to represent
a large number on the fly) you can store numerical
values of any size at all, with the single limitation
being the amount of memory in the computer.
You have to go many, many orders of magnitude
beyond a googolplex before that becomes an impediment.

>There is not enough time left for most of the big companies to change to 4-byte dates. The FAA will probably be compliant sometime in 2007:
> http://www.house.gov/science/graham_02-4.htm

This will no doubt be a pain for them, but how
many of these instances of non-compliance will
actually affect the world at large? Not many.

> Ever see what happens when a non-compliant mainframe attempts to divide by the date "00"? Nothing. That is, everything stops, all millions of lines of code and thousands of programs come to a complete standstill, leaving just an error message that says something like "cannot divide by zero."

And all you have to do to fix it is reboot and not
do that again. How many programs do you think
*divide* dates? Dates are added and subtracted
and used as sort keys. Almost *no* code anywhere
enter multiples or divides dates.

> Other than that, I understand everything you just said, and agree with most of it... I guess it's just the extent of the problem that we disagree over. For instance, I wouldn't want to be in a hospital when a computer thinks it's been 99 years since I got my last shot, or hooked to a life-support system if the lights go out...

Hospitals don't administer shots by computer.
A person does it, and if it sees that the computer
thinks it's been 99 years since your last shot,
even a stupid person will do a double take.
And life support computers don't even store dates.

> Jesus told us not to worry about what we will eat and drink tomorrow, because He already knows about our problems and cares for us,

Amen to that.

> Don't worry about what you'll eat or drink, but at the same time don't waste the time God has given you.

Good advice. All I'm saying is that, from all I
can tell from my experience being in the industry
(where we also have to deal with making our software
Y2K compliant...a task we're almost done with, by
the way), we're not going to be hit very hard as
a race. A few incidents where people were stupid
and didn't prepare ahead of time will no doubt
occur, but they won't be crippling to huge numbers
of people.

> Good grief. I've gone and written a book. I'm sorry! I didn't have a clue it was going to end up being this big when I started.

That's ok. I would prefer that people overstate
(I'm not saying you did) than understate. I've
been to too many message boards on the web
where the entirety of people's message content
was placed in the subject line and the body left
blank.