Silly season

Thu Dec 23 21:01:07 UTC 1999

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/