Re: Silly season

["Steve Dispensa" <dispensa () maverick mwis net>]

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 () virgin relcom eu net>
To: Roeland M.J. Meyer <rmeyer () mhsc com>
Cc: 'North America Network Operators Group' <nanog () 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 () 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/