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/