Silly season

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,

	Ehud Gavron
	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
>2000
>> year. This means the installation of the future time, isn't it? Why don't
>just
>> tesh y2.038k too (it's not big difference how many different frauded dates
>to
>> test - one /1 January 2000/ or 2 (1 Jan and this, 2038 /which day it will
>be,
>> 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
>of
>> > the package. However, this does NOT correct databases that already have
>a
>> > 32-bit time_t (which shouldn't be the case, but is a good probability
>[lazy
>> > coders]).
>> > Ergo, even the fact that 90% of the computers will be 64-bit safe by
>2038
>> > won't save us. Stored data will have to be checked and the conversion
>will
>> > 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
>real
>> > problem is data in long-term storage, where inertia is the name of the
>game.
>> >
>> >
>> >
>>
>> Aleksei Roudnev,
>> (+1 415) 585-3489 /San Francisco CA/
>>
>>