[26317] in North American Network Operators' Group
RE: Silly season
daemon@ATHENA.MIT.EDU (Roeland M.J. Meyer)
Thu Dec 23 14:46:45 1999
Reply-To: <rmeyer@mhsc.com>
From: "Roeland M.J. Meyer" <rmeyer@mhsc.com>
To: "'North America Network Operators Group'" <nanog@merit.edu>
Date: Thu, 23 Dec 1999 11:44:57 -0800
Message-ID: <016901bf4d7e$31f94120$ecaf6cc7@lvrmr.mhsc.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <m121DuS-000g5eC@most.weird.com>
Errors-To: owner-nanog-outgoing@merit.edu
> 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.
