Computer bugs in the year 3200
Bill Vaughn
bill at ur-cvsvax.UUCP
Sat Feb 16 01:44:40 AEST 1985
> In article <7927 at brl-tgr.ARPA> ron at brl-tgr.ARPA (Ron Natalie <ron>) writes:
> >> For those of you fixing things in your software:
> >>
> >> The year 2000 *is* a leap year, despite what many algorithms tell you.
> >> The year 2400 is *not* a leap year.
> >>
> >> With minimal effort, you can make things work until 2399. You may be
> >> subject to complaints after that.
> >>
> >Now you've really got me confused. Why is 2400 not a leap year?
>
> (msd = mean solar day)
> 1 year = 365.2422 msd = 365 + 1/4 - 1/100 + 1/400 + error
> That's why we have:
> leapyear 1 out of 4
> non leap year 1 out of 100
> leapyear 1 out of 400 (So 2400 is a leap year.)
> Read any basic astronomy book.
> --
Hmmm. Let's take this two more steps. Since our error over the long run
will be +0.0003 msd, we can reduce this by taking a leap year back every
3200 years making the error now -0.0000125 msd. But this can be corrected by
replacing one of those leap years we just took back every 80,000 years
and we're right on the money, assuming 365.2422 msd/year is exact and
that it's constant over this period of time. I'm sure neither of these
assumptions are correct ;-).
So, for the time being, I claim that 3200 should *not* be a leap year, (nor
should any year divisible by 3200, except if it's also divisible by 80,000).
OK you hackers, I want those algorithms updated tomorrow. :-)
Bill Vaughn
UNIV. OF ROCHESTER
Center for Visual Science
{allegra,seismo,decvax}!rochester!ur-cvsvax!bill
Guru: What's the matter?
Novice hacker: When I do this, it hurts. (shows guru his core dump)
Guru: DON'T DO THAT!!
More information about the Net.bugs
mailing list