Talk:Leap year/Archive 2

Archive 1

Archive 2

Archive 3

WikiProject Time assessment rating comment

Want to help write or improve articles about Time? Join WikiProject Time or visit the Time Portal for a list of articles that need improving.
—Yamara ✉ 22:17, 12 February 2008 (UTC)

Algorithm

Is Algorithm Necessary?

Is this really necessary? i have seen no precedent for explanation via algorithm, and I feel like the prior explanations do a better job than the code.The freddinator (talk) 04:52, 29 February 2008 (UTC)

Yes, it is really necessary. I know of at least two people who went here looking for it and were happy to have found it. Ysth (talk) 10:06, 3 March 2008 (UTC)

Two out of how many million?? Is that really worth putting in some computer/Boolean code in an article that has nothing to do with this type of code at all.

To be honest, constructing these bits of code/algorithm were about the first assignment I had in computer class ever (at about age 12). I do not recall creating this bit of algorithm from the rules as difficult at all, that is how trivial that information is. Arnoutf (talk) 09:58, 23 January 2010 (UTC)

Swarms of programmers (both novice and expert) all over the Internet both link to and copy the algorithm published here, which is inefficient. My first attempt to improve the algorithm's efficiency, which was "dumbed down" to show regard for ease of understandability was removed on two bases:

First, that there is "no need for efficiency". I disagree. Every human using any flowchart or algorithm desires to attain the simplest and easiest route to the correct answer. It serves no purpose to intentionally provide a less than optimal algorithm where an optimized algorithm is no more complicated to understand.

Second, that the words "is not 0" are somehow not easily understandable by "non-programmers". Again, I disagree. The published algorithm utilizes "modulus" in place of "is divisible by". Modulus (even though a link is provided) is far more obscure to average individuals than "is not 0". This argument makes little sense to me.

Thus, I have now provided a note to programmers with a link to an external discussion of an optimized algorithm in the predominant C language, which is easily understood by most every programmer and is the basis for many other languages.

I can show that multitudes of programmers utilize the Wikipedia algorithm in their code, and thus, the Wikipedia algorithm probably has been implemented in thousands of computer programs. It is a huge disservice to the community to not include (at the least) a notation and reference to an algorithm that is more appropriate for programmers. Kriceslo (talk) 21:52, 21 July 2012 (UTC)

Hello, I don't see any discussions about which algorithms are welcome and which not on. I could not find any comments pointing to discussions in the page history either, and the current standard seems to have arisen three years ago as a coincidence of an unexplained edit where anonymous user removed the whole section and a registered user readded it reduced a few days later. I find the current pseudocode implementation not suitable for use in any real programming language because it duplicates the is_leap_year -block. --hydrox (talk) 10:02, 2 October 2010 (UTC)

Any algorithm is considered original research and hence forbidden on Wikipedia unless it was previously published, in which case the source must be cited. — Joe Kress (talk) 06:09, 18 October 2010 (UTC)

Algorithm Mathematics/Efficiency

2008

The opening paragraph reads...

In the Gregorian calendar, the current standard calendar in most of the world, most years whose division by 4 equals an integer are leap years.

It should be "equals a natural number" not an integer.

I don't have an account, but my name is Steven Oliver for further reference. --70.90.250.13 (talk) 13:13, 29 February 2008 (UTC)

Apparentley, wikipedia is not at all reliable because everyone can edit it. So most people write absoloute rubbish. It is not reliable, as i have proved by deleting everything that previous people have writen. aren't i clever. so guess what? i'm clever. i repeat : wikipedia is nopt reliable. do not use it. especially for coursework. My A level History paper counted for nothing because one of my sources was wikipedia, and the examiner discualified me. I'm just trying to help is all. :):):):):):):):P —Preceding unsigned comment added by 80.177.228.194 (talk) 14:28, 29 February 2008 (UTC)

So if you are trying to help, why do so on an out of the way discussion page? With your paper, you must always use additional sources, and it is clearly stated in Wikipedia policies that Wikipedia is not accepted under most exam boards as a reliable source. Therefore, it is your own fault. microchip08 (talk) 21:02, 29 February 2008 (UTC)

Why did you make a username? —Preceding unsigned comment added by IvaAsh (talk • contribs) 00:56, 4 November 2008 (UTC)

2009

Could a registered user please delete the phrase "(terms may be grouped either way)" from the shorter version of the algorithm. The terms must be grouped specifically as "(year % 4 == 0 AND year % 100 != 0) OR (year % 400 == 0)". [SEE REBUTTAL BELOW] Other groupings are not materially equivalent. If proof is required, refer to the following truth table.

Let the propositional variable 'A' stand for: "The year number is evenly divisible by 4" (year mod 4 is o) Similarly, let 'B' stand for: "The year number is evenly divisible by 100." Let '~B' stand for the negation of B. Let 'C' stand for: "The year number is evenly divisible by 400"

The suggested Boolean is A & ~B v C (reads 'A' and 'not B' or 'C'). It is proposed that this is equivalent to both (A & ~B) v C as well as A & (~B v C).

0	A	B	C	(A&~B)vC	A&(~BvC)
1	T	T	T	T	T
2	T	T	F	T	T
3	T	F	T	T	T
4	T	F	F	F	F
5	F	T	T	T	F
6	F	T	F	F	F
7	F	F	F	T	F
8	F	F	F	F	F

As seen in lines 5 and 7, the truth value differs from one grouping to the next. Only the first grouping correctly corresponds to the specifications in the rest of the article and to the expanded algorithm. To be a leap year, the year number must either be divisible by 400 (C is true) or it must both be divisible by 4 and not divisible by 100 (A is true and B is not, i.e., '(A & ~B)'). —Preceding unsigned comment added by --Guest User 209.213.81.214 (talk) 16:52, 22 December 2009 (UTC)

However, in this case if something is divisible by 400 then it is also divisible by 100, and if something is divisible by 100 then it is also divisible by 4, which means that only the following rows are relevant:

0	mod 4	mod 100	mod 400	(A&~B)vC	A&(~BvC)
1	T	T	T	T	T
2	T	T	F	T	T
4	T	F	F	F	F
8	F	F	F	F	F

-- AnonMoos (talk) 22:08, 22 December 2009 (UTC)

I've added your table to the article, suitably modified and corrected. — Joe Kress (talk) 05:02, 23 December 2009 (UTC)

Rebuttal to argument about grouping algorithm terms: While the truth table first presented demonstrates the expressions "(A&~B)vC" and "A&(~BvC)" are not equivalent, the definitions of A, B, and C when determining leap years are such that the expressions ARE, IN FACT, EQUIVALENT. The second truth table omits the differing cases (that are irrelevant to determining leap years). Grouping the algorithm terms as "A&(~BvC)" produces a more optimized expression. Why? Because evaluating "A" (year is divisible by 4) is enough to end the evaluation in three out of four cases. "B" and "C" do not require any evaluation except when "A" is true. The grouping preferred in the comment above, "(A&~B)vC", requires evaluation of "C" even when "A" is false (three out of four cases). THEREFORE, the expression "A&(~B&C)" is both optimal and proper, and should be preferred. Kriceslo (talk) 22:06, 19 March 2014 (UTC)

They're completely equivalent in truth value in all cases which arise in determining leap years (since 400 is a multiple of 100 which is a multiple of 4), and Wikipedia is not compendium of code optimization and computational efficiency tips and tricks (see discussions below)... AnonMoos (talk) 00:18, 30 March 2014 (UTC)

First point: I agree on equivalency. That is precisely my point (above). Second point: While I also agree Wikipedia is not a "compendium of code optimization", I avidly dispute Wikipedia's historical publication of a less than optimum algorithm, especially since the most optimized algorithm is no more complex. The present pseudocode is optimum and should be the adopted preference. Kriceslo (talk) 00:30, 30 March 2014 (UTC)

2011

The current algorithm is inefficient if modulo is an expensive operation (as it is on many embedded architectures). More importantly, it seems to solve the problem backwards. I think it'd be more clear (and efficient) to solve the problem in the opposite direction. Specifically:

if year modulo 4 is 0
    if year modulo 100 is 0
        if year modulo 400 is 0
            then is_leap_year
        else
            not_leap_year
    else
        is_leap_year
else
    not_leap_year

(W.R.T. efficiency, the current algorithm performs an average of 1/400*1 + 399/400*(1/100*2 + 99/100*3) = 2.985025 moduli per execution, while the one listed above performs an average of 3/4*1 + 1/4*(99/100*2 + 1/100*3) = 1.2525.)

Inverting the if's (but retaining the same program order) results in the following, which may be further preferable due to its lack of nesting.

if year modulo 4 isn't 0
    not_leap_year
else if year modulo 100 isn't 0
    is_leap_year
else if year modulo 400 isn't 0
    not_leap_year
else
    is_leap_year

(Another way of saying my point: the English prose above doesn't begin with "If the year is divisible by 400"; it starts with "If the year is divisible by 4." Allowances can be made for efficiency, but this is actually less efficient.)

69.245.179.230 (talk) 00:00, 16 May 2011 (UTC)

69.245.179.230's algorithm does seem more efficient, and just as easy to understand, as the algorithm presently in the article. Jc3s5h (talk) 01:24, 16 May 2011 (UTC)

I don't want to try to judge which one is best, but one point is that we're really not concerned with computational efficiency when it comes to brief pseudo-code snippets -- legibility and easy comprehensibility should be the only criterion... AnonMoos (talk) 06:57, 16 May 2011 (UTC)

69.245.179.230's algorithm is entirely just as legible and easy to comprehend (change "isn't" to "is not"). Why would you not adopt an improvement? Efficiency *is* a legitimate criterion, especially when it is no more complicated. Kriceslo (talk) 04:11, 22 July 2012 (UTC)

2012

The article has some pseudocode at Leap year#Algorithm to show how to determine when a year is a leap year. I reverted a recent edit (diff) that introduced a note which included "For an optimized test to determine leap years see Most Efficient Leap Year Test". Searching for "July 2012" on this talk page shows two recent comments on the issue. In response to a request at my talk, I am asking for opinions on the above edit—because many programmers would consult Wikipedia concerning an issue like this, should the article include a note regarding a better algorithm? Johnuniq (talk) 04:42, 22 July 2012 (UTC)

If they're consulting Wikipedia, then they're looking at the wrong place, because we're not a programming "tips and tricks" site. For such brief pseudo-code snippets, legibility and comprehensibility are more important than efficiency -- and leap-year determination code would rarely be in an inner loop anyway, as far as I can see... AnonMoos (talk) 06:36, 22 July 2012 (UTC)

Demand reliable algorithm source

In view of the fact that the algorithm has been changed and challenged over and over again, most recently today, I have removed it and demand that it not be restored unless it is quoted character-by-character from a cited reliable source. Jc3s5h (talk) 15:14, 8 April 2014 (UTC)

RESPONSE: Thank you for your interest in the algorithm. I am the author of the algorithm now posted. The source is this article found at Stack Overflow: "Most efficient leap year test". Stack Overflow is well-respected and immensely popular question and answer site for professional programmers. My "answer" posted there is the highest rated leap year response which qualifies it as "peer reviewed" in the programming industry. I hope you will find it reliable and authoritative. It is extremely important that Wikipedia provides a correct and efficient algorithm as many programmers find the Wikipedia article first in their Internet search results and implement the algorithm found here. Past debate has asked whether posting the best/fastest algorithm should be of concern. I contend that it is a major concern as many programmers use the algorithm found here without further researching this basic subject. I have viewed numerous highly technical and mathematical Wikipedia pages and see no reason to declare this algorithm too complicated not to publish here. Best regards. Kriceslo (talk) 02:34, 9 April 2014 (UTC)

Stack Overflow is indeed a "well-respected and immensely popular question and answer site for professional programmers." It is just great for competent programmers who are capable of evaluating whether a particular suggestion is correct or helpful. But it is a effectively self-published source which has no mechanism to deomonstrate the contributors meet Wikipedia's definition of an expert: "an established expert whose work in the relevant field has been published by reliable third-party publications." Therefore it is not a reliable source. I am removing it. Jc3s5h (talk) 13:12, 9 April 2014 (UTC)

Ah, but you neglect to account for the peer review process by which answers on Stack Overflow are read and rated by the programming community. Furthermore, it is easily demonstrable that the "Algorithm" is no more complicated than the plain-text which you have not disputed and which does carry multiple expert citations (see "Gregorian calendar" here on this very article:

...most years that are integer multiples of 4 are leap years...The Gregorian Calendar therefore omits 3 (Julian) leap days every 400 years, which is the length of its leap cycle. This is done by omitting February 29 in the 3 century years (integer multiples of 100) that are not also integer multiples of 400.

Compare with the algorithm:

if year is not divisible by 4 then not leap year ("years that are multiples of 4")
else if year is not divisible by 100 then leap year ("omitting in the three century years...")
else if year is divisible by 400 then leap year ("...that are not also multiples of 400")
else not leap year

For an unquestionably credible source, please see "NIST - National Institute of Standards and Technology: Leap year"

The extra day is added every four years to compensate for most of the partial day. However, this is a slight over-compensation, so some century years are not leap years. Only every fourth century year (those equally divisible by 400) is a leap year.

Again, compare with the plain-text algorithm:

if year is not divisible by 4 then not leap year ("extra day is added every four years")
else if year is not divisible by 100 then leap year ("some century years are not leap years")
else if year is divisible by 400 then leap year ("those equally divisible by 400 is a leap year")
else not leap year

This is grade-school logic. It is utterly beyond me why a three-test 3rd grade math problem needs any more scrutiny. But we can apply additional scrutiny if you like... again quoting from NIST:

For instance, 2000 was a leap year, but 1900, 1800 and 1700 were not.

2000 IS divisible by 4 (fails test 1), IS divisible by 100 (fails #2), IS divisible by 400 (passes #3) = LEAP YEAR
1900 IS divisible by 4 (fails test 1), IS divisible by 100 (fails #2), IS NOT divisible by 400 (fails #3) = NOT LEAP YEAR
1800 IS divisible by 4 (fails test 1), IS divisible by 100 (fails #2), IS NOT divisible by 400 (fails #3) = NOT LEAP YEAR
1700 IS divisible by 4 (fails test 1), IS divisible by 100 (fails #2), IS NOT divisible by 400 (fails #3) = NOT LEAP YEAR
2012 IS divisible by 4 (fails test 1), IS NOT divisible by 100 (passes #2) = LEAP YEAR
2013 IS NOT divisible by 4 (passes test 1) = NOT LEAP YEAR
2014 IS NOT divisible by 4 (passes test 1) = NOT LEAP YEAR
2015 IS NOT divisible by 4 (passes test 1) = NOT LEAP YEAR
2016 IS divisible by 4 (fails test 1), IS NOT divisible by 100 (passes #2) = LEAP YEAR

Sir or madam: What more substantiation do you require? If you are not yet satisfied, then please marks the section in dispute and contact me via e-mail. This is beyond ridiculous (in my humble opinion). Kriceslo (talk) 14:04, 9 April 2014 (UTC)

It has been repeatedly disputed. In essence, readers don't believe you because you are not an expert and Stack Overflow is not a reliable source. I am pursuing dispute resolution at WP:Reliable sources noticeboard#Stack Overflow a reliable source for an algorithm? Jc3s5h (talk) 14:28, 9 April 2014 (UTC)

Well I appreciate the dispute. Although the equality to the NIST's own verbage is so plain on its face it's like disputing what a simple sentence says. How does one reliably prove the meaning of "Jack and Jill went up the Hill?"

Here's another overwhelmingly reliable source: The latest stable Linux kernel source code: [1]

You will note lines 45 through 49 define the leap year function at the heart of every Linux based computer (like your Android phone):

/* Nonzero if YEAR is a leap year (every 4 years,
  except every 100th isn't, and every 400th is). */
#define	__isleap(year)	\
  ((year) % 4 == 0 && ((year) % 100 != 0 || (year) % 400 == 0))
#endif

Linux uses the EXACT same three tests: year divisible by 4, 100, and 400 (using the '%' modulo operator):

"(year) % 4 == 0" translates to "year is divisible by 4"
"(year) % 100 != 0" translates to "year is not divisible by 100"
"(year) % 400 == 0" translates to "year is divisible by 400"

The three tests are linked together by "&&" and "||" (boolean AND and OR operators) like so:

year-is-div-by-4 AND (year-is-not-div-by-100 OR year-is-div-by-400)

Which is the same as:

if year is divisible by 4 --AND--
{
  if year is not divisible by 100 then leap-year
     --OR--
  if year is divisible by 400 then leap-year
}
else
{
  not-leap-year
}

The above is EXACTLY the same as the pseudocode I offer. The difference is I have inverted the first test to eliminate the nested if-then tests:

if year is NOT divisible by 4 then not-leap-year
else if year is not divisible by 100 then leap-year
else if year is divisible by 400 then leap-year
else not-leap-year

I can cite a hundred more references on numerous programming sites that are exactly the same, but I have cited NIST and the Linux kernel which are indisputable. Furthermore, I can find thousands of Wikipedia pages that cite thousands of factually unreliable sources such as newspapers and blogs. What gives? Sigh. Kriceslo (talk) 15:14, 9 April 2014 (UTC)

How many computer programs have fallen over dead because a logical test included the inversion operation when it shouldn't have, or performed logical tests in the wrong order? Translation of even the simplest English description into pseudo code or a computer program requires expertise in computer programming. Readers should not be required to evaluate whether pseudo code is logically identical to an English description. Also, nothing in the talk page counts; readers don't normally consult the talk page.

Furthermore, an appropriate source will put its statements in context, describing the range of validity of an algorithm, and specifying the operation of any operator that might vary from one computer language to another. (Not an issue for "divisible", but I understand some computer languages or environments give different results for modulo operations on negative numbers.) Also, the fact that years are treated as integers should be explicitly stated. Jc3s5h (talk) 15:41, 9 April 2014 (UTC)

Why is it that the textual description at "Gregorian calendar" is not in dispute? It is not a character-for-character copy of any cited expert source. We're dealing with pseudocode here that takes no more critical analysis of accuracy than the textual version does.

The logical inversion is correct and is easily seen to be so. I have over three decades expertise in computer programming. This is not "code" that requires academic analysis. I could easily generate results for 5,000 years as proof, but I believe you might dispute even that based upon the "unknown" 5,001st year. I have to say I am astonished at this whole debacle. I am as interested in accuracy here as are you. I've put uncounted hours into the matter to counter the "bad" or lacking algorithms previously published here and elsewhere. It's unbelievable that self-evident accuracy still requires such a costly battle for the truth. I certainly don't see such a challenge over three sentences anywhere else in this article. But thanks for your time. Kriceslo (talk) 15:55, 9 April 2014 (UTC)

Jc3s5h, I appreciate where you are coming from here. I've got some further ideas but you've already soaked up my entire morning. I'm going to cool off a bit and will post here at a later time or date. Thanks. Kriceslo (talk) 16:42, 9 April 2014 (UTC)

The basic problem here is the algorithm section is constantly being questioned or changed. We need a source where it will be immediately obvious to well-intentioned editors that their musings on the subject are infinity less credible than the cited source. Furthermore, when someone edits in bad faith, the editor that reverts the bad-faith editor needs a solid source to back him/her up to any administrator if the reversion is questioned. The editor reverting a bad-faith editor, or an administrator dealing with the bad-faith editor, is not likely to be an experienced computer programmer, accustomed to converting English requirements into code (or even pseudo code). Jc3s5h (talk) 16:50, 9 April 2014 (UTC)

I have found an algorithm in a reliable source, but I consider it unsuitable. The source is N. Dershowitz and E. M. Reingold, Calendrical Calculations, Cambridge U. Press, 2008, p. 48-49. It is valid for both positive and negative years if astronomical year numbering is used. The algorithm is:

gregorian-leap-year(g-year) is defined as (g-year mod 4) = 0 and (g-year mod 400) $x\notin A$ {100, 200, 300}

I don't consider it suitable because the reader would have to realize the material to the right of "is defined as" is a boolean test. Also, the algorithm is quite suitable for the Lisp language used by Dershowitz and Reingold, because Lisp contains built-in functions to determine if a value is a member of a set. It isn't so convenient for other programming languages. Also, the order-of-evaluation of operations is non-obvious.Jc3s5h (talk) 17:23, 9 April 2014 (UTC)

This is the kind of problem I would expect with virtually any referenced algorithm: the context will need to be explained. It won't hurt to reference code or pseudo-code from an RS, but that doesn't mean we have to copy it verbatim. What you're asking for is a "WP-ready" source -- we don't need that, and precisely what we're looking for may not exist. (What programming language would be acceptable; what logic constructs need to be explained, etc, etc). Transforming sources into WP material is what WP editors are *supposed* to do. The frequent edits you mention really aren't a problem and are corrected almost in real time (and providing even the most Reliable Source possible won't stem the edits, believe me). As I've said on the Notice Board, I think it would suffice to add an HTML comment to the algorithm saying that the algorithm is the result of consensus on the talk page, and that suggested changes should be discussed there first. Also, I agree with you that the algorithm section needs more documentation: to tie it more closely to the definition; that the year is an integer variable; the range of years the algorithm is designed for; that the order of evaluation is designed to dispatch common cases quickly; and that care needs to be taken translating divisibility into a specific programming language. -- Elphion (talk) 16:30, 10 April 2014 (UTC)

This should not be so difficult. We are not deciding which flavor of ice cream is best. This is math.

First things first- the live algorithm is unacceptable in its formatting and must be changed. (else? else if? is this correct? if so, why the hell is the pseudocode on the wiki page written like a paragraph? if statements need indentations for clarity, even in pseudocode, actually, even more so pseudocode) Now that we are changing it, we might as well come back to this discussion and decide what is actually correct. "Credible" sources are apparently unavailable and we must do the work for the world ourselves. This is how I propose we make a decision on this:

1. The pseudocode that works with every given year wins. If there is none, then the one with the most success in positive years wins. If there is a tie, move on to 2.
2. The pseudocode that has the most overall success wins. If there is a tie, move on to 3.
3. The pseudocode that has that has the fastest run time wins. If there is a tie, move on to 4.
4. The pseudocode that is the closest to English wins.

This specific section on the wiki page is for programmers only. If someone else is reading this, it does not matter what this is, he or she will most likely not understand this anyways. Just get what works. No arguing should ever be happening. There is proof and that is it.

I have a question. If this section can only be understood by programmers, then why does the live pseudocode try to type like code without using pre tags? EVanCleef (talk) 00:24, 12 December 2014 (UTC)

The evaluation machinery you propose is not necessary. If you have a concrete alternative to propose, go ahead and suggest it. You have made three concrete suggestions: (1) we should choose some program language and fasten on its control keywords; (2) we should use a monospaced font; and (3) we should indent the if statements (according to an arbitrary format you provide a link to). I'm not convinced that any of these would be an improvement. As to (1), we typically avoid specific languages -- that's why it's in pseudocode, to maximize clarity to humans rather than machines. I don't think indentation is necessary; I find the current formatting far more readable than the image you link to. And pseudo-code is often displayed in proportional fonts, simply because proportional fonts are easier to read if lining up the character columns is not particularly important (as it's not in this case). Come to that, I don't think any language specification actually *requires* that you use a monospaced font (Fortran possibly excepted :-). -- Elphion (talk) 06:43, 12 December 2014 (UTC)

EVanCleef -- "that has the fastest run time" should have absolutely zero influence when weighed against clarity and comprehensibility. Clarity and comprehensibility should be overwhelmingly the most important factors... AnonMoos (talk) 07:46, 12 December 2014 (UTC)

2015

Jc3s5h, why the revert? [2] I think readers would find the IP's version easier to understand. --NeilN ^{talk to me} 20:49, 19 January 2015 (UTC)

First, see the endless bickering at #Algorithm. Second, it is not universally understood that some, but not all, programming languages introduce comments by having a "#" as the first non-whitespace character on the line. Jc3s5h (talk) 21:10, 19 January 2015 (UTC)

[ec] It's a reasonable alternative, though it depends on short-circuit evaluation of Booleans (which is usual but not universal) to dispatch common cases with the same efficiency. That's worth a note in the intro to the algorithm. However, I suspect the reason for the quick revert was IP's blowing right through the comment at the head of the section. -- Elphion (talk) 21:12, 19 January 2015 (UTC)

Forget the "#" - the average reader wouldn't know it's a programming construct and would just treat it as "hey, this denotes a comment". I found the IP's version much easier to follow with the examples. --NeilN ^{talk to me} 21:16, 19 January 2015 (UTC)

I feel the long-standing version easier to understand, and I am surprised that some feel 5.40.118.244’s version easier. I find if-if constructions inherently difficult to understand, and I (almost) never use them in my own code. By this I mean an if statement immediately followed by an if statement inside the then block. Indefatigable (talk) 17:58, 20 January 2015 (UTC)

Similarly to Indefatigable, I experienced a brain-freeze when I encountered the if-if construction. Jc3s5h (talk) 22:43, 20 January 2015 (UTC)

4000 AD

"4000 AD" should be "AD 4000" —Preceding unsigned comment added by 165.200.127.254 (talk) 15:29, 29 February 2008 (UTC)

Actually it should be 4000 CE. 78.35.107.83 (talk) 18:48, 20 July 2010 (UTC)

Leaplings? Leapers? What are Leap Year Babies called? LEAPLE!!!

I have never heard of either term for Leap Year Babies until this week.

The term Leaplings appears to come from a mid-1990s children's book. http://www.wordspy.com/words/leapling.asp It's really cute until you are old enough to vote.

I read an article this week that said adult Leap Year babies were called Leapers. Oh Really?? Only since 1996...

I am VERY interested in the term for a Leap Year Baby because I am one. Leaplings is insulting if you are grown. Leapers is mediocre. I prefer Leaple.

Juniorgoddess (talk) 04:23, 1 March 2008 (UTC)

What will you call ONE (what's singular of Leaple)? Leaperson? Lerpson? Lepperson? 71.198.34.87 (talk) 02:00, 5 December 2009 (UTC)

How about just people. — Preceding unsigned comment added by 68.41.217.15 (talk) 15:38, 19 July 2013 (UTC)

Removed NYT article link

Removed link to New York Times article [3] because it adds no real relevant facts beyond what was already contained in this Wikipedia article, but does contain some inaccuracies (such as implying that the Roman calendar was lunar before 45 B.C., and repeating some long-debunked historical nonsense about alleged "11 days" riots in England in 1752). AnonMoos (talk) 12:48, 1 March 2008 (UTC)

Easter

"The Gregorian calendar was designed to keep the vernal equinox on or close to March 21, so that the date of Easter (celebrated on the Sunday after the 14th day of the Moon that falls on or after 21 March) remains correct with respect to the vernal equinox.[3] The vernal equinox year is about 365.242374 days long (and increasing), whereas the average year length of the Gregorian calendar is 365.2425."

I think this is wrong. Easter date is based on the Ecclesiastical equinox which does not accurately track the astronomical equinox. This paragraph seems to imply that easter is chosen based on the true astronomical equinox. Gigs (talk) 17:21, 14 March 2008 (UTC)

Yes, but the Gregorian calendar was devised so that the ecclesiastical vernal equinox would track the astronomical vernal equinox as closely as is possible using very simple leap-year rules ("4 EXCEPT 100 EXCEPT 400"). The vernal equinox year was also more relevant for the devisers of the Gregorian calendar than the mean tropical year. A lot of articles on calendars complain about the discrepancy between the mean tropical year of 365.2422 days and the Gregorian year of 365.2425 days (the Revised Julian Calendar was even an attempt to "fix" this), even though the Gregorian calendar was actually more intended to approximate the vernal equinox yearof 365.2424 days... AnonMoos (talk) 18:42, 14 March 2008 (UTC)

The papal bull Inter gravissimas does state that its intent was to return the vernal equinox to March 21, and its rules were intended to prevent it from again receding from March 21, so its rules should have approximated the vernal equinox year. However, as of 1582 the vernal equinox year could not be measured with sufficient precision separately from other kinds of tropical years. Even though the Gregorian rules may seem to approximate the vernal equinox year, it just so happens that those rules result in a year (365.2425 days (decimally) or 365;14,33 days (sexagesimally)) which exactly equals the year given in astronomical tables available to the Gregorian reformers. Specifically, the years given in the Prutenic Tables and in its predecessor, the Alfonsine Tables, when rounded to two sexagesimal places are equal to the mean Gregorian year (see Gregorian reform of the calendar cited in Gregorian calendar#References). But the year of those tables was supposed to be the mean tropical year, not the vernal equinox year. So it is a fortunate accident that the Gregorian year is nearer the vernal equinox year than it is to the mean tropical year. — Joe Kress (talk) 10:15, 16 March 2008 (UTC)

Rounding to 365;14,33 is mentioned on page 99 of Gregorian reform of the calendar, where J.D. North refers to a note by Noel Swerdlow, The origin of the Gregorian civil calendar, Journal for the History of Astronomy 5 (1974) 48-49. Although North used rounded, a better term would be truncated since all three years listed were greater than 365;14,33. Specifically, these (tropical?) years were

365;14,33,9,57,... Alphonsine tables

365;14,33,11,12,... De revolutionibus (Copernicus)

365;14,33,9,24,... Prutenic tables

Their average value (disregarding the unstated terms beyond the fourth sexagesimal place) is

365;14,33,10,11 or 365.2425471 days

which differs considerably from the modern mean tropical year, 365.242190 days.

Gregorian reform of the calendar also mentions on page 103 that in 1583 John Dee explained how the vernal equinox year differed from the autumnal equinox year, using Copernicus's De revolutionibus and the Prutenic tables, although his values no doubt differed quite a bit from modern values. — Joe Kress (talk) 03:39, 24 March 2008 (UTC)

Yes, but the accuracy of the Gregorian calendar should still be judged according to the original intention to approximate the vernal equinox year (not the mean tropical year). AnonMoos (talk) 09:55, 28 April 2009 (UTC)

128 Year rule.

Can anybody explain this nonsense?

A system of 128-year-based leap years has been proposed,[7] and it can be adopted directly without any modification to current leap year calculations until the year 2048 because no year between now and 2048 is divisable by 128. This rule gives a mean year of 365 + 1/4 − 1/128 = 365.2578125 days, which is 365 days, 6 hours, 11 minutes, and 15 seconds.

I don't think a missing leap year every 128 years means you subtract 1/128. Secondly, whoever did the calculation evidently missed the obvious, ie that the resulting year is far too long (over an hour a year), since the aimed-for result has to be closer to 365.2422, not larger than 365.25!!

Silas Maxfield (talk) 14:13, 1 April 2008 (UTC) I see where the error is now. I will make the calculations and modify it accordingly. Silas Maxfield (talk) 14:41, 1 April 2008 (UTC)

The math is wrong 365 + 1/4 − 1/128 = 365.2421875 much closer to 365.2422 than 365.25 and marginally closer than 365.24. Subtracting 1/128 does make sense as it means over a 128 year period, the average days per year will result in 365.2421875 days. — Preceding unsigned comment added by 216.113.168.141 (talk) 22:11, 9 September 2011 (UTC)

... but that's not the year length that the calendar attempts to match. The northward equinox year is currently 365.242374 days, but will change over the centuries. Dbfirs 20:42, 10 March 2015 (UTC)

Different length years

Hey guys just wanted to point out that under this page: http://wiki.riteme.site/wiki/Mean_tropical_year and this page: http://wiki.riteme.site/wiki/365_(number) the decimal number for the average number of days in a year is a little different! There could be an error on one of these pages and sorry if I'm way off or have reported this incorrectly Groovenectar (talk) 04:03, 25 June 2008 (UTC)

No error exists. The Tropical year page has the most precise value available whereas the Leap year page only has an approximation. — Joe Kress (talk) 06:57, 25 June 2008 (UTC)

1700

about this : "but 1700, 1800 and 1900 were " in the article , actually 1700 was leap, because the reform was introduced by 1752. Its easy to check with any Unix machine - $ cal 2 1700 —Preceding unsigned comment added by Mil dim (talk • contribs) 16:01, 30 June 2008 (UTC)

I'm clarifying that 1700 was not leap in the papal bull—the later 1750 calendar act ignored it as past history, so 1700 was leap in the British Empire (and in other countries that adopted the Gregorian calendar later). — Joe Kress (talk) 05:07, 1 July 2008 (UTC)

Shorter formula

How about this formula:

if Y mod 4 – sgn (Y mod 100) + sgn (Y mod 400) = 0 then leap

Is it worth of being included? — Hellerick (talk) 14:21, 8 April 2009 (UTC)

Here's a tenary operator, but what's with the unnecessary sign function?

(year % 400 && yead % 4 ? true : false)

ChazZeromus (talk) 23:46, 10 September 2009 (UTC)

yead? —Preceding unsigned comment added by 217.8.130.17 (talk) 07:49, 14 January 2011 (UTC)

Change of Calendar; localisation of next leap year

The article says "For example, 1600 and 2000 were leap years, but 1700, 1800 and 1900 were not.". That's only true if the context is remembered; I suggest inserting "in the Gregorian calendar, ", for safety.

It would seem useful to add something like "All Christian countries used the Julian Calendar before 1582; countries changed to the Gregorian Calendar on various dates from 1582 to the 20th Century." with a link to the details.

The first section has, in source : "The next Gregorian leap year will be in 2012."

Firstly, it will not be in 2012, it will be 2012.

Secondly, an undated article should not contain date-dependent statements. One cannot rely on anyone updating that in a timely fashion; and it's not clear whether it should be updated at the beginning or end of 2012 or of 2012-02-29. Moreover, it needs to be updated at different UTC instants for different locations. Either calculate the 2012 using the reader's local time, or omit it; it's not needed.

82.163.24.100 (talk) 15:18, 24 September 2009 (UTC)

ERROR - 2000 was NOT a leap year

In your article you state: "......2000 were leap years..." IF a year that ends in "00" IS divisible by 400, it is NOT a leap year. You need to change this. I don't have the where-with-all to get around Wikipedia and all the channels needed to perform an official change. Very few people know this. You MUST change it - or many more people will be ill-informed! DSB1263 —Preceding unsigned comment added by 174.89.136.75 (talk) 18:05, 9 November 2009 (UTC)

Murder of Kayla Rolland took place on February 29, 2000. Hellerick (talk) 03:05, 10 November 2009 (UTC)

"I don't have the where-with-all to get around Wikipedia and all the channels needed to perform an official change" What? Oh, you mean this whole thing. 71.198.34.87 (talk) 02:04, 5 December 2009 (UTC)

Don't tell him to change the article, because what he asserted is simply factually false... AnonMoos (talk) 02:42, 5 December 2009 (UTC)

2000 was a Leap Year: I remember distinctly because I had a birthday and would have been annoyed if I'd had to go 8 years without a birthday. — Preceding unsigned comment added by 86.20.86.244 (talk) 17:11, 29 February 2012 (UTC)

Sports events

What is the relevance of this section in this article? Can it be deleted? —Preceding unsigned comment added by João Graça da Nóbrega (talk • contribs) 15:01, 1 March 2010 (UTC)

These events are only held every four years during leap years, at least between 1904 and 2096. However, they were/will be held in 1900 and 2100 even though they are not leap years. — Joe Kress (talk) 08:37, 2 March 2010 (UTC)

This relevance should be stated clearly in the article and linked to a reference. Falcor84 11:30, 14 May 2010 (UTC) —Preceding unsigned comment added by Falcor84 (talk •contribs)

That's just silly. The leap status of the year is irrelevant to the holding of the events, it just so happens that we haven't had a non-leap 4-year since 1900. My vote goes for this section to be removed. — GWinkless

Birthdays section quote

Does the following quote, taken from the Birthdays section, make any sense to anybody? I can't even begin to comprehend what it's meant to mean.

If a period fixed by weeks, months, and years does not commence from the beginning of a week, month, or year, it ends with the ending of the day which precedes the day of the last week, month, or year which corresponds to that on which it began to commence.　 But if there is no corresponding day in the last month, the period ends with the ending of the last day of the last month.

Greg 13:11, 9 November 2010 (UTC) —Preceding unsigned comment added by Kingturkey (talk • contribs)

It is a legal quote, which are usually hard to comprehend. Some examples would help. If a period begins in the middle of the week on Wednesday then it must end on the preceding day of the week, Tuesday, for the period to contain a whole number of weeks. Similarly, if a period begins on the tenth day of a month, it must end on the preceding day of a month, the nineth, for the period to contain a whole number of months. But if a one month period began on January 31 of a common year, it must end on February 28 because February 29-30 does not exist. — Joe Kress (talk) 09:57, 11 November 2010 (UTC)

The Pirates of Penzance?

The statement about "The Pirates of Penzance" seems like trivia here. Should that be removed?--72.19.91.193 (talk) 06:48, 30 March 2011 (UTC)

It's by far the most culturally famous case of February 29th birthday paradoxes in the English-speaking countries... AnonMoos (talk) 13:08, 30 March 2011 (UTC)

Problem

My computer can't show the big picture that's on this page. Alphius 21:28, 20 May 2011 (UTC)

• Never mind. It's showing it now. Alphius 21:30, 20 May 2011 (UTC)

When was it invented

I read through the article and I could not find the date leap years started have they been going on since 0 A,D, (or B,C, I don't know which) A random thought came that if the leap years started later (in the 1000 A,D, and so on) maybe we have some time to add to our calenders. — Preceding unsigned comment added by 24.222.50.221 (talk) 03:40, 25 December 2011 (UTC)

The Julian calendar repeats itself every 4 years, and it is not affected by the Christian era which was introduced much later. "AD 0" a.k.a. 1 B.C. was indeed a leap year, but not the first one. 5 B.C., 9 B.C., 13 B.C. etc were leap years as well.

In fact after Caesar's death the order of leap years was somewhat messed up, but later it was corrected, and effectively the rule "every 4th year is a leap year" is applicapble to all the years since the introduction of the Julian calendar in 45 B.C. Hellerick (talk) 16:23, 26 December 2011 (UTC)

After the Julian calendar was implemented in 45 BC, leap years occurred every three years (triennial leap years) for the first 36 years. To correct the excessive number of leap days, leap years were suspended for 12 years before leap years every four years (quadrennial leap years) became permanent. The details, including the first triennial leap year and the first quadrennial leap year depend on a particular scholar's reconstruction. Several can be found at Julian calendar#Leap year error. The proleptic Julian calendar avoids this complication by extending the quadrennial leap year back in time forever. — Joe Kress (talk) 18:44, 26 December 2011 (UTC)

"Leap Shifting of the Gregorian Calendar"-Original Research?

There does not appear to be any references to back up this chart, or the accompanying prose. The statement, "Therefore making 4000 a non-leap year will probably not be necessary", has been tagged as "vague". It seems to me to be not only "vague", but original research as well. Do we have any references to support this table and the statements based on it? Joefromrandb (talk) 13:32, 29 February 2012 (UTC)

A lot of people over the last few centuries have speculated about further corrections that could be made to the Gregorian algorithm on a millennial scale (and the Revised Julian calendar is one partial attempt at such), but the fact that year length in terms of days is continually decreasing in a way that is not entirely predictable means that no fixed rule will be accurate over thousands of years... AnonMoos (talk) 18:12, 29 February 2012 (UTC)

365.2425 is the average.

Re GFHandel's edit, (365.25*400-1)/400 = 365.2475 I can't see any way to dispute this. Or to put it another way, 365 days x 400 years = 146000, plus the 99 leap days = 146099, and 146099 divided by 400 = 365.2475 whichever way you look at it. Number36 (talk) 12:09, 29 October 2012 (UTC)

The correct number is (365.25*400 − 3)/400 = 365.2425, because the Gregorian calendar omits three leap days, not one, in 400 years. -- Elphion (talk) 12:34, 29 October 2012 (UTC)

Yes, but what you're failing to take into account is... Hmm. Oh. I'll get my coat.Number36 (talk) 13:05, 29 October 2012 (UTC)

more about febuary

February 29 is a date that usually occurs every four years, and is called leap day. This day is added to the calendar in leap years as a corrective measure, because the earth does not orbit around the sun in precisely 365 days.

The Gregorian calendar is a modification of the Julian calendar first used by the Romans. The Roman calendar originated as a lunisolar calendar and named many of its days after the syzygies of the moon: the new — Preceding unsigned comment added by 41.211.199.11 (talk) 11:14, 4 February 2013 (UTC)

¿Should we mention that having Centennial Leap years only every 500 years would be more accurate?

Since the creation of the Gregorian Calendar, we have measured the tropical year more accurately. It is roughly 365.242,19 mean solar days:

365.242,19 mean solar days

If one multiplies .242,19 times 500, one gets 121.095:

.242,19 * 500 = 121.095

That means that in 500 years, if one has only 121 Leap Years (no Centennial Leap Years except on Centennial Years divisible by 500), the Calendar will be only .095 days off (02 Hours 16 Minutes 48 seconds off).

I know that this is not a pressing issue because we have over 38 decades to decide whether we should reschedule the Leap Year scheduled for 2,400 to 2,500, but it we might as well get an early start. — Preceding unsigned comment added by 76.102.233.65 (talk) 09:32, 23 October 2014 (UTC)

No. The musings of calendar hobbyists are not worth mentioning here. In this article it suffices to mention systems that are in use, and mention that the Calendar reform article describes serious proposals that have attracted attention in reliable sources. Jc3s5h (talk) 13:17, 23 October 2014 (UTC)