> > 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.

Wouldn't the user interface port require a replacement or repair in the hardware itself to make it compliant? (I'm not a Y2k programmer myself, I'm just asking.)

>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.

But, um... isn't our Government's most common computer is the old 486? (see link)

> 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.

I've never programmed an OS before in my life, so I can't speak for what it would take to repair one. Nevertheless, the OS isn't the only part of a computer that can be non-compliant. (see link)

>
> > 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.

Yeah, but that's not my point I was making when I said, "there's no cure"... I'm referring to existing technology, and the task involved in repairing everything that's already out there. That's a good guideline to keep in mind when making a new program, but it's a totally different ball game when you're using 20 year-old tape reels with millions of records that have a 2-byte space allocated for each date... and again, I'm probably in over my head on this issue, as I've never actually programmed on a mainframe myself. What I'm saying is just what I've heard the mainframe programmers say themselves.


>
> >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,

Actually, I wasn't thinking about them. I was thinking about how much of a pain it would be to us. What are we going to do if the FAA isn't compliant in time? Flying a 747 is definately out of that picture... and I'm sure that would have serious consequences for our economy if shipping gets all kinked up.


>but how
> many of these instances of non-compliance will
> actually affect the world at large? Not many.

Yeah, just a "few" instances... you know, like 15% of American businesses
http://web.lexis-nexis.com/more/cahners/11380/3894835/2

9% of UK's businesses
http://webserv.vnunet.com/www_user/plsql/pkg_vnu_news.right_frame?p_story=66101

the nation of Australia
http://www.williamsinference.com/2506Y2K.htm

...nothing much, really.


> > 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.

Is it really that easy on a mainframe? I mean, we're not talking about some desktop computer here. (again, a disclaimer of my ignorance into the willy world of mainframes, but I thought that it some of the larger ones hours to reboot)... and even if it doesn't crash, what about the corrupted data that is added/subtracted to/from the year 1900?

>
> > 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.

I may have been wrong... check out this USA Today article...
http://www.usatoday.com/life/cyber/tech/ctd154.htm

and "the lights going out" was referring to a power loss...
http://www.house.gov/science/couffou_3-20.html
...because I don't think the NRC would allow a publicly acknowledged unsafe nuke plant to operate (and backup generators aren't faultless).


>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),

Yess! Some good news! That was one of the things I was hoping I'd hear! Thank you! Got any more good news? (you wouldn't happen to know *how* close you guys are, would you?)


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.

What is your basis for being so confident? The results of your company? Research into the results of others? If it is others, who are they? Can you provide any evidence to support your optomism? (I'm not attacking anything, I just want to know.)