calculating leap years
Lerxt
dave at murphy.UUCP
Sat Oct 18 07:32:17 AEST 1986
Summary: does anyone remember January 5, 1975?
Line eater: enabled
In article <813 at ethos.UUCP>, ggw at ethos.UUCP (Gregory Woodbury) types:
>The programs may not "need" to handle the dates beyond that 20 year interval
>but when the programs that are being written now hit the end of the century
>there are going to be a lot of installations and programs that are going
>to be suprised come "March 1" to see the computer say "Feb 28, 2000".
>In at least one industrial control system, there is going to be a discrepancy
>between the VAXen and their comm controllers. I had modified the comm system
>date routines to handle the 2000 non-leap year, and was told to take it back
>out "because the system won't be in use that long." That's the worst excuse
>I have ever heard for managemental incompentence - how many systems (especially
>commercial ones) are still running programs that were written more than 20 years
>ago [more than you might think] just because they never can be bothered to
>re-implement (when emulation is available).
I know of one case where something similar has already happened, and it
was a major disaster for a lot of people. DEC had the misfortune of
having every TOPS-10 system in the world come to a screeching halt on
January 5, 1975. Reason: on that date, a 13-bit date counter field in
the kernel overflowed. Apparently the author didn't think TOPS-10 would
be around long enough to need a bigger field.
---
It's been said by many a wise philosopher that when you die and your soul
goes to its final resting place, it has to make a connection in Atlanta.
Dave Cornutt, Gould Computer Systems, Ft. Lauderdale, FL
UUCP: ...{sun,pur-ee,brl-bmd}!gould!dcornutt
or ...!ucf-cs!novavax!houligan!dcornutt
ARPA: wait a minute, I've almost got it...
"The opinions expressed herein are not necessarily those of my employer,
not necessarily mine, and probably not necessary."
More information about the Comp.lang.c
mailing list