nanog mailing list archives
Re: Silly season
From: Ehud Gavron <GAVRON () ACES COM>
Date: Thu, 23 Dec 1999 14:33:04 -0700 (MST)
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 () 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 in2000year. This means the installation of the future time, isn't it? Why don'tjusttesh y2.038k too (it's not big difference how many different frauded datestotest - one /1 January 2000/ or 2 (1 Jan and this, 2038 /which day it willbe,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 seasonGreg 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 partofthe package. However, this does NOT correct databases that already havea32-bit time_t (which shouldn't be the case, but is a good probability[lazycoders]). Ergo, even the fact that 90% of the computers will be 64-bit safe by2038won't save us. Stored data will have to be checked and the conversionwillobsolete 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 therealproblem is data in long-term storage, where inertia is the name of thegame.Aleksei Roudnev, (+1 415) 585-3489 /San Francisco CA/
Current thread:
- Silly season Sean Donelan (Dec 22)
- Re: Silly season Alex P. Rudnev (Dec 22)
- Re: Silly season Richard Steenbergen (Dec 22)
- Message not available
- Re: Silly season Richard Steenbergen (Dec 22)
- Re: Silly season Andrew Brown (Dec 22)
- Re: Silly season Greg A. Woods (Dec 23)
- RE: Silly season Roeland M.J. Meyer (Dec 23)
- RE: Silly season Alex P. Rudnev (Dec 23)
- Re: Silly season Steve Dispensa (Dec 23)
- Re: Silly season Ehud Gavron (Dec 23)
- Re: Silly season Andrew Brown (Dec 23)
- Re: Silly season Deepak Jain (Dec 23)
- Re: Silly season Richard Steenbergen (Dec 22)
- Re: Silly season Tim Wolfe (Dec 23)
- Re: Silly season Richard Steenbergen (Dec 23)
- Re: Silly season Alex P. Rudnev (Dec 22)
- Re: Silly season Andrew Brown (Dec 23)
- Re: Silly season Alex P. Rudnev (Dec 23)
- Re: Silly season Richard Steenbergen (Dec 22)
- Re: Silly season Alex P. Rudnev (Dec 23)