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