GAVRON at ACES.COM
Thu Dec 23 21:33:04 UTC 1999
Y2K: We'll know in 9 days. We'll suffer for a bit afterward.
32bitbug: I think we'd best leave this one alone until somewhere
around 2020. By then I don't think most current system
kernels will be in use, and, well, I'll be retired.
Happy New Year to you all,
ACES Research/RMI.NET Tucson
>I don't know how big of a deal is being made about 2.038K on a corporate
>management level, but it would seem that the ensuing months would be just
>about a perfect time to address this issue. After all, many companies have
>teams for the date-field issue right now, and we've gotten pretty good in
>the past couple of years at analyzing this problem. It would only make
>sense to immediately move on to the 2038 work after Y2K settles down. Let's
>just not wait until 2035 to deal with it this time, huh?
> - Steve
>----- Original Message -----
>From: Alex P. Rudnev <alex at virgin.relcom.eu.net>
>To: Roeland M.J. Meyer <rmeyer at mhsc.com>
>Cc: 'North America Network Operators Group' <nanog at merit.edu>
>Sent: Thursday, December 23, 1999 3:01 PM
>Subject: RE: Silly season
>> Btw, an idea. Some of you are tsting their system as they will work in
>> year. This means the installation of the future time, isn't it? Why don't
>> tesh y2.038k too (it's not big difference how many different frauded dates
>> test - one /1 January 2000/ or 2 (1 Jan and this, 2038 /which day it will
>> exactly?/ date).
>> And my suggestion is that y2038k will be a very serious problem for the
>> Unix-based systems and some network protocols, not as Y2K problem are.
>> On Thu, 23 Dec 1999, Roeland M.J. Meyer wrote:
>> > Date: Thu, 23 Dec 1999 11:44:57 -0800
>> > From: Roeland M.J. Meyer <rmeyer at mhsc.com>
>> > To: 'North America Network Operators Group' <nanog at merit.edu>
>> > Subject: RE: Silly season
>> > > Greg A. Woods
>> > > Sent: Thursday, December 23, 1999 11:28 AM
>> > >
>> > > [ On Wednesday, December 22, 1999 at 23:58:21 (-0500), Andrew
>> > > Brown wrote: ]
>> > > > Subject: Re: Silly season
>> > > >
>> > > > it would be better, imho, to go to a 64 bit signed time_t, but that
>> > > > would be a major flag day.
>> > >
>> > > "would be"!?!?! :-)
>> > >
>> > > No, it *WILL* be an important day, but it will happen on a per-system
>> > > basis (and perhaps per-protocol basis if indeed there are any network
>> > > protocols carrying time_t or similar values).
>> > Those of us implementing 64-bit OS (Alpha, Merced, etc) get this as part
>> > the package. However, this does NOT correct databases that already have
>> > 32-bit time_t (which shouldn't be the case, but is a good probability
>> > coders]).
>> > Ergo, even the fact that 90% of the computers will be 64-bit safe by
>> > won't save us. Stored data will have to be checked and the conversion
>> > obsolete many backup tapes. What I am saying is that there is still a
>> > data-migration issue, just like Y2K. The problem is only transitive in
>> > protocols and running code, there is not much inertia there, but the
>> > problem is data in long-term storage, where inertia is the name of the
>> Aleksei Roudnev,
>> (+1 415) 585-3489 /San Francisco CA/
More information about the NANOG