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.
|