On Fri, 13 Jun 1997, C Matthew Curtin wrote:
> This is a limitation in how Unix implements the clock. Specifically,
> it does so as seconds since epoch (midnight, January 1, 1970), and the
> data type used to store that number (a 4 byte signed integer). A 4
> byte signed integer will overflow at 2147483648. As a result,
> 2147483648 seconds after the epoch, there will be an overflow, such
> that when you make a time() call, you'll get unpredictable results.
A couple of points;
1) This is far less a problem than many of the current Y2K problems we
face. My firm, among other things, has a division which does RPG/COBOL
consulting work on AS/400's and other IBM type boxen. The single largest
problem is not so much the code itself, it i that many large companies
have VERY LARGE legacy systems to which the original source is unavailable
or for some other reason untenable. Or, in a 20,000,000 line COBOL
application, the code is there but with few comments, and the original
programmer has long since left the firm. The primary source of the Y2k
problem is that in most implementations of COBOL and RPG II in use, the
year portion of a date is represented only by an offet from the century,
e.g "97" instead of "1997", and date arithmetic assumes this format. So,
come 2000, to use an example given already, the social security system
will do a simple arithmetic check, and presume that "04" means 2004, which
will either be an error state, or false data, depending on when it happens
;)
2) Perhaps I've missed something, but the UNIX epoch problem shouldn't be
difficult to avoid. The use of 32-bit time_t should go away with
64-bit OS's, and I would certainly think that in the next 42 years we can
manage that ;) Also, since this is an OS-level problem, and not generally
an application-level problem, the solution should be far less nasty to
implement.
References:
|
|
