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