Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: Silly season

  • From: Alex P. Rudnev
  • Date: Thu Dec 23 16:14:13 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@mhsc.com>
> To: 'North America Network Operators Group' <nanog@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/






Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.