Francais | Deutscher | Italiano | Português | Español Add a URL


Julian Calendar - Leap Year FAQ
Perpetual Calendar | Leap Year Calendar

Is 2000 really a leap year?

This is probably the most contentious issue on Lenon.com, judging from the amount of feedback we've received. So, let's get this out of the way first...

There appear to be three different mindsets at work:

  • 2000 is a leap year
  • 2000 is not a leap year
  • 2000 is a super leap year / double-leap year

The super / double-leap year nonsense is supposedly an Internet hoax or the end result of a bad answer on the Hollywood Squares quiz show, and is being fueled by a gross misunderstanding of the rules that determine leap years. This misguided logic argues, since years divisible by 4 are leap years AND years divisible by 400 are leap years, that makes the year 2000 a super / double-leap year with two days added to February, 2000. Rest assured there won't be a 30-day February in 2000 or any other year. Please, don't waste your time sending us feedback or e-mail on this absurdity. We're not changing our minds :)

Of greater concern for the world at large is the notion that 2000 is not a leap year. We've done a considerable amount of research on this and will publish our findings further down this page, but in the meantime...

Simply put, the Year 2000 is absolutely a leap year! Don't let anybody tell you differently. If they do, they don't understand how to correctly determine a leap year.

How do we determine leap years?

These three simple rules have determined leap years since 1582:

  • years divisible by 4 are leap years
  • years divisible by 100 are not leap years
  • years divisible by 400 are leap years

However, since the addlepated minds of our programmers and engineers can't seem to grasp such simplicity, we've also included a swell new revision by the International Electrical Engineers, entitled IEE W2715 Rules (G3.4.3):

  • (a) If the number of the year is divisible by 4 then the year is a Leap Year, except
  • (b) If the number of the year ends in 00 then the year is not a leap year; however
  • (c) If the number of the year ends in 00 and the year is divisible by 400 the year is a Leap Year.

That's it! Take your pick.

Why do we have leap years?

The length of the year isn't an even number of days. For all practical purposes, the year is 365.25 days long. That is, there's an extra six hours left over every calendar year. In order to keep our calendars in step with the seasons, we need to "cook the books" every four years by adding an extra day, February 29th.

How long have we had leap years?

This trivial point is often overlooked, but is the root cause of much confusion. For the purpose of this simple discussion, let's just say: leap years have occurred, for the most part, every four years since 46 B.C. After 8 A.D., every year divisible by 4 was a leap year. After 1600, every year divisible by 4 was a leap year except 1700, 1800 and 1900. In other words, leap years have been around for over two-thousand years and have served us impeccably well since the Gregorian reformation in 1582.

What's this got to do with the Julian calendar?

The "Original" Julian Calendar, authorized by Julius Caesar in 46 B.C., was based on a 28-year cycle of indication. It added a 366th-day every four years. This was a dandy idea, except for the fact that the year is actually 365.24219 days long, not 365.25. Oh, well. Nice try, Jules!

In 1582, Pope Gregory XIII decided enough was enough. "PG-13" took the bull by the horns and decreed October 4th would become October 15th to correct for an estimated 10 days of error in the calendar. Pope Gregory's advisors had surmised, given enough time and error, Easter would eventually fall on Christmas; an intolerable situation. Brrr...

The change from the Julian Calendar to the Gregorian Calendar involved turning the simple 4-year rule for leap years into a more complex one in which century years should only be leap years if they were divisible by 400. For example, 1700, 1800 and 1900 are not leap years whereas 2000 is.

So what's the problem?

The problem is some calendars, computers and computer programs have a leap day built into the year 2000, some don't. This is an indisputable fact. The only thing left to wonder is what the effect will be, come February 29th, 2000.

ABC News says, "The confusion comes from a difference of opinion as to whether the 400-year cycle extends from 1000 or from 2000 AD. If the latter is true, then a 29-day February is appropriate for the coming millennial year. If not, big troubles are ahead".

Falling slightly short of a wholesale indictment of ABC News and Hugh Downs as liars and instigators, we've received some strongly worded e-mail decrying ABC / Downs as the sole champions of this "retroactive dating" argument. Having said that, they're apparently dead-right about "big troubles" laying ahead for us.

Quoting ABC News once again, "Because our computers and calendars are not all the same on this - and because nobody, it seems, is doing anything about this anomaly - we're headed for a mess".

Why should we believe you?

Well, let's see what Microsoft has to say:

"The year 2000 is a leap year. Additionally, many custom routines to determine leap years are not Year 2000 compliant because they only work with two digits of the year. If your application requires logic to determine leap years, be sure to test your routine to ensure it works in the 20th and 21st centuries. This is a Year 2000 problem because many developers still believe (incorrectly) that 2000 is not a leap year. Because of this, many custom leap year algorithms will incorrectly identify 2000 as a non-leap year."

To hear a chilling admission from Microsoft (RealPlayer G2 required) - click here

and Information Week:

"Then there's the fact that year 2000 is a leap year. How the Gregorian calendar works is not a secret. The three rules are available in any encyclopedia, but it would appear that many programmers are totally unaware of how the calendar operates, as evidenced by indignant letters to the editor received by computer magazines, saying 2000 is not a leap year. No automatic solution will address leap-year issues 100% correctly. Why? Because there are so many wonderfully creative ways in which to calculate or look up leap years or to arrive at "day of the week" information in what many would consider arcane methods."

and NASA:

"Another issue with the date is the leap year and the year 2000 is a leap year. There are three rules for determining a leap year. If the year is divisible by 4, then it is a leap year unless it is divisible by 100. This condition says that the year 2000 is not a leap year. The years 1800 and 1900 were not leap years. The year 2000 is a leap year because, following the last rule, it is also divisible by 400. The problem is not limited to desktop computers only. Aircraft systems, security systems, facility systems (elevators, air handlers, etc.), and telephone systems have the potential for related problems. Any system which uses a two-digit date could be suspect. Today a lot of these systems are monitored or operated by some sort of computer system. The problem waiting to happen."

and WSR Consulting Group - computer litigation experts:

"The gentleman I was talking to was a mid-level information systems manager for a large regional transportation company. After talking for awhile, I asked whether he had heard of the Year 2000 problem and how he and his company were preparing for it. A broad smile covered his face. "We fixed it already!" he replied. I was impressed to say the least - but also a little bit skeptical. I followed with, "Did you know that the year 2000 was a 'leap year?' " "Heck" he responded. "it's not only a leap year - it's a 'super leap year!' - it has thirty days! " I asked myself in disbelief, "Where do otherwise sane folks get these crazy ideas?" After more discussion, we finally tracked down this erroneous conception to something that he had heard on a famous television quiz show."

and The University of Texas at Austin, Computation Center:

"Cal, by David Oster, is a calendar desk accessory suitable for individual use or for shared use over a Appleshare or TOPs network. It is a permanent calendar, for any year covered by our current calendar. It handles the fact that 2000 is not a leap year, but 1900 is (the division by 400 rule)."

and The University of Delaware, Network Working Group:

"If bit 0 is set, the UTC time is in the range 1968-2036 and UTC time is reckoned from 0h 0m 0s UTC on 1 January 1900. If bit 0 is not set, the time is in the range 2036-2104 and UTC time is reckoned from 6h 28m 16s UTC on 7 February 2036. Note that when calculating the correspondence, 2000 is not a leap year".

and The Assembly of the Western European Union:

"Computer systems influence and govern our daily lives more than ever before and this situation is accelerating with the information technology revolution. This equally applies to military technology upon which the security of nation states, and defense alliances, have become increasingly dependent. This includes, of course, NATO, WEU and their member states. Now, many IT managers are becoming aware of the Year 2000 (Y2K) problem relating to computer systems. This suggests that all but the most recent systems will fail to recognize the millennium date change and will fail to function properly, leading to widespread confusion and chaos. Many applications will also fail to recognize the Year 2000 as a leap year. Defense experts in the United States and the United Kingdom have admitted that both countries could be rendered "defenseless".

and Computer Associates:

"The end result is that the Year 2000 is, in fact, a leap year. So what does this mean for those of us in data processing? With all the confusion surrounding leap year rules, our systems are riddled with faulty leap year logic. Some systems fail every four years - such as in the case of the Arizona State Lottery and New York Taxi Cab systems in 1996. Throughout our data processing systems, date logic itself has evolved in a non-standardized fashion. Many date routines were written on the fly, and exist as multiple modified manifestations of themselves because programmers kept reinventing the wheel. Worse yet, sometimes date logic doesn't even exist as a standardized routine, but exists instead in the form of hard-coded logic, where the calculation is performed line-by-line in an extremely non-standardized way.".

and Unique Systems Inc:

"The year 2000 poses a particularly challenging problem for companies and organizations of all sizes. The so-called "Millennium Bug" has the potential of affecting all software and equipment with embedded chips. This can affect anything from your desktop clock to the embedded electronics in your phone. The problem mainly concerns 2 digit dates such as "01/01/00" that can be interpreted as either January 1st, 2000 or January 1st, 1900. But, it gets even more complicated when you consider the year 2000 is not a leap year (unlike previous centuries).".

and Fat Pages:

"PS: Bill_Engels@allianzlife.com writes: The year 2000 is NOT a leap year. Leap years are those divisible by 4, and not divisible by 400. The next leap year is actually 2004. I fixed the script -- it got simpler"

and the musings of a Meme Gardner:

"Many "personal opinions" are not individual, but culturally created and propagated meme complexes, rooted in nearly identical form in many hosts. Imagine what will happen on February 29, 2000 when thousands or millions of computers become confused about the date (an amazing number of programmers think that the year 2000 is not a leap year; it is). Will this best be understood as an individual phenomenon in each computer's "mind", or as a gestalt based on running copies of the same shared software?"

and Moore Resource Systems:

"Making an application year 2000 compliant may not be good enough however. Two or more year 2000 compliant applications may not be compliant when they interact, depending upon how they handle the year (as two or four digits). One must be conscious of the way applications interact to avoid these complications."

and finally the US Navy:

"Related Problems - The Leap Year - The year 2000 is a leap year - Gregorian calendar problem due to general ignorance - Julian calendar problems too - Different representations for storing the year, month, and day in a fixed number of digits and shortcuts to converting dates to full Julian date format will all overflow during the period 1998-2001."

Well, you get the picture, right?

How do we know the leap year rules are correct?

Thinking about the math, if every 100 years we skip a leap day, our calendar year would compute to 365.25 - .01 days or 365.24 days long. Then, to catch that other .00219 day we add a leap day every 400th year, or + .0025 days, we get 365.2425 days which is pretty close to the tropical year of 365.24219 days. That leaves a built in error of only .00031 days, or one day every 4000 years.

Pretty good thinking for 1582, huh? Not really... People were much smarter in those days. Even 100 years ago, any 4th grade student could have told you 2000 would be a leap year. But, we'll save that discussion for later :)

Lenon.com features two Online Julian Calendars, one for leap years and one for non-leap years. These two calendars cover it all. We hope you'll find them useful.

Upcoming Leap Years (For the next 50 years):

2000, 2004, 2008, 2012, 2016, 2020, 2024, 2028, 2032, 2036, 2040, 2044, 2048.

If you just can't get enough of this stuff, here's more reading for you:

To learn about the Julian Calendar and its history, follow this link.

To see if we're getting smarter or not, follow this link.



Copyright | Disclaimer | Privacy | Feedback | Home
Copyright ©  1996-2009  Lenon.com