9 Dec
2000
9 Dec
'00
8:41 a.m.
Don Maslin wrote:
On Fri, 8 Dec 2000, Sellam Ismail wrote:
Jerome Fine replies:
And that will continue to happen so long as the most important aspect
is short term revenue considerations. I understand that 2038 (or around
that date) is when 32 bit C subroutines will have a problem. Hopefully
by then, most code will be 64 bit and the problem will no longer exist.
The operating system that I am interested in did not get the Y2K patches
and the current version still costs $ US 1600 for the distribution media
and document set. And if the user does not have a license for the last
revision from 1992, a license is also specified for another $ US 900.
Since the old version from 1985 is a hobby version and free to use
under certain restricted conditions, I want to make a Y2K version
available for hobby users and it will not be that much more effort
to bring it to a Y10K level. The only real question is the calendar
which will likely have a leap year or two omitted in the next 8000 years.
But which one is still in question.
Sincerely yours,
Jerome Fine
On Fri, 8 Dec 2000, Jerome Fine wrote:
But, of course, that is how we got into the Y2K problem
originally. Many people have told me that I am crazy to even
consider this
possibility, let alone do the work, but why save data for 10,000 years?
Does anyone have any advice as to how to handle the problem that
the calendar can't be predicted exactly so far into the future?
I don't
know...will it matter? Are you intending that people will still
be using these operating systems 8,000 years from now or are you only
concerned about the data itself?
Still, it wouldn't hurt to add another digit in the year field. Of
course, by that time you'll be dead, so what do you care? Let some future
genius figure it out :)