Talk:Leap year

New Leap Year Procession

Section collapsed - pending supporting sources

[Note: If and when supporting sources for the post below can be provided, please uncollapse this section, delete this note and re-initiate this discussion (had been deleted with this edit)] The International Union of Pure and Applied Chemistry and the International Union of Geological Sciences have jointly recommended using approximately 365.24219265 ephemeris daits (day and night) as the length of the tropical year (in the year 2000). Since 1 year period is 0.24219265 daits longer than a whole number of daits, it takes 4 years (4 * 0. 24219265 = 0.96877060) to gain nearly a full dait. thus the calendar adds a leap dait every 4 years. Therefore, a 4 year period is now 0.03122940 daits shorter than a whole number of daits, and it takes 32 * 4 years (32 * 0.03122940 = 0.99934080) to lose nearly a full dait, thus the calendar subtracts a leap dait every 128 years. Finally, a 128 year period is now 0.00065920 daits longer than a whole number of daits, and it takes 1516 * 128 years (1516 * 0.00065920 = 0.99934720) to gain nearly a full dait, but the calendar ignores a leap dait error every 194048 years. Years Leaps Error Correction Procession 1 0 +0.24219265 4 0 +0.96877060 4 1 –0.03122940 +1 +4 128 32 –0.99934080 128 31 +0.00065920 -1 -128 194048 46996 +0.99934720 extinction if (year is not exactly divisible by 4) then (it is a common year) else if (year is not exactly divisible by 128) then (it is a leap year) else (it is a leap year) So much easier, how about it? 4wikin9 (talk) 12:07, 22 January 2016 (UTC)

Algorithm Accuracy

I'm not necessarily suggesting this should be added because it's not currently recognized as necessary (and it won't be necessary for over 1000 years), but in order to keep the progression of leap/common year accurate over time, the algorithm would have to be extended as follows:

if (year is not divisible by 4) then (it is a common year)
else
if (year is not divisible by 100) then (it is a leap year)
else
if (year is not divisible by 400) then (it is a common year)
else
if (year is not divisible by 3200) then (it is a leap year)
else (it is a common year)

In other words, even though the year 3200 is divisible by 400, it will have to be a common year to keep the calendar accurate. The next steps in this progression (obviously not necessary to worry about any time soon) would be the year 86,400 (a leap year even though divisible by 3200) and the year 13,478,400 (a common year even though divisible by 86,400). - Embram (talk) 08:56, 8 December 2014 (UTC)

First of all, which year do you use? Most likely the tropical year, but the Gregorian calendar was intended to follow the March equinox cycle (necessary to determine the date of the Easter), which is slightly different. Second, the length of all the cycles are changing. There is no point to declare a 3200-year cycle because after just one cycle the length of the year will be different already, and it will be necessary declare another calendar cycle with different length. De facto it would mean that the calendar will be occasionally corrected without any fixed system. Hellerick (talk) 11:53, 8 December 2014 (UTC)

Read the "ΔT" article to see why the corrections that would be needed so far in the future cannot be predicted. Jc3s5h (talk) 14:33, 8 December 2014 (UTC)

Well, that's a matter to be decided by the Pope, or United Nations, or Federation of Planets Council, or whoever decides these things 1000 years from now, sometime after the year 3000. Regardless of whether the tropical year or equinox cycle is followed, the year 3200 would have to be the next year of adjustment in order to keep the current system in which the adjustment year alternates between being a leap year and a common year, in which case the next year-period of adjustment must be divisible by the previous year-period. Do the math yourself; I think you'll find that in either case, eight 400-year cycles is when the next one-day adjustment will be needed (the one after that, 80,000+ years away, is another matter). This is a course just a matter of interest to think about how large or small an error is generated under the current system if the 400 year cycle continues. I'm not suggesting we change the current page, of course, since the Gregorian calendar uses the 400 year cycle, and that's that. Perhaps by the year 3200, instead of having to fiddle with leap days mankind will be able to keep the calendar in line with the equinox by adjusting the rotation of the Earth or its distance from the Sun (if they care about such things at all by then, or haven't already switched to a different calendar system). - Embram (talk) 14:45, 8 December 2014 (UTC)

Embram -- The best-informed people do not think it would be useful to lay down the law now for hypothetical calendar adjustments which would not be applied for many centuries. The one semi-official attempt to do so, the so-called Revised Julian calendar, is a very dubious "improvement" over the Gregorian calendar... AnonMoos (talk) 23:58, 8 December 2014 (UTC)

AnonMoos -- As I think I indicated, I agree with you. This is all academic. It's just a measure of how big (or small) is the error over time that remains with the Gregorian calendar. - Embram (talk) 02:24, 9 December 2014 (UTC)

John Herschel suggested a similar correction many years ago, but it was never adopted. As stated above, the calendar is already an excellent match to the year it is intended to follow (which is not the mean tropical year), and by the time the correction is needed, there will be changes in the length of the year that cannot currently be predicted with an accuracy appropriate to the correction. You might like to read the article on Milankovitch cycles. Dbfirs 20:11, 10 March 2015 (UTC)

The algorithm as it is is a bit ugly to read. Being explicit on the logical condition might be quicker to understand. if ( year divisible by 4 and year not divisible by 100) or year divisible by 400) then leap year else normal year 191.115.28.196 (talk) —Preceding undated comment added 21:27, 25 September 2015 (UTC)

The ordering of the tests is explained in the first paragraph under "Algorithm". -- Elphion (talk) 16:36, 4 October 2015 (UTC)

The ordering of the tests is the same. "year divisible by 4" being first here and "year not divisible by 4" there is the same test. The algorithm is poorly written since most computer languages use "Short-circuit_evaluation" ie as soon as the logical expression is false it stops. Also as indicated below most computer languages include "modulo" so there is no need for the warning about division. The above algorithm has got an unmatched close bracket which is not needed.

iif ( year divisible by 4 and year not divisible by 100 or year divisible by 400) then leap year
else normal year

Where "divisible by N" can be "modulo N is zero".87.102.44.18 (talk) 11:52, 6 March 2016 (UTC)

Why not simply

function isLeapYear(year) {
    return year is divisible by 4
        && (year is not divisible by 100 || year is divisible by 400)
}

...? It's simple, it works, and it more closely matches the original Julian scheme mentioned in the Gregorian Calendar section. 165.117.243.254 (talk) 15:31, 28 December 2018 (UTC)

Every leap year is every 4th year. To not overcomplicate things when using just the regular date and calendar, all you need to do is to check if the modulo 4 of year = 0, you can do this simply by checking:

C++ / Java: leapyear = year % 4; if (leapyear == 0) { // we got leapyear}

Visual Basic: leapyear = year mod 4: if (leapyear = 0) then ' we got leapyear

This is a formula I derived earlier this year on a bet (to produce the most succinct possible code for making this determination, written in C#) which should properly deduce whether a provided year is a leap year, for any year in the set { 0 < year < 3200 }:

// isLeapYear will be TRUE if the value of "year" represents a leap year:
bool isLeapYear = (year % ((year % 100)>0 ? 4 : 400)) == 0;

— 216.240.6.210 (talk) 05:39, 20 March 2016 (UTC) (if you use this code, please provide attribution!)

No, no! That's NOT the most succinct, AND it is less than most-efficient! The ">0" test requires a subtract operation on many CPUs. You should be using "!=0" here (testing for zero/not-zero is built into every CPU I know of). Even then, the code isn't most-efficient; it uses costly division (modulo) twice, and the ternary operator is really just hiding a third operation, and there's unneeded parentheses. This code is an improvement, but still not most-efficient:

// Perhaps, most succinct, but NOT most efficient because 100th year test is performed every time
bool isLeapYear = (year & (year % 25 != 0 ? 3 : 15)) == 0;

The "most efficient" code below replaces a costly modulo (division) operations with bit-wise logical AND operations, and terminates after only ONE operation for three-quarters of all cases. The costly division (modulo 25) for the 100th year test only executes for "4th year" cases:

// Most efficient leap year test
// See: http://stackoverflow.com/questions/3220163/how-to-find-leap-year-programatically-in-c/11595914#11595914
bool isLeapYear = (year & 3) == 0 && (year % 25 != 0 || (year & 15) == 0);

— Kriceslo (Kriceslo) 12:16, 23 November 2016 (UTC)

— Preceding unsigned comment added by 37.196.158.254 (talk) 01:14, 11 January 2016 (UTC)

No, that's not true. 1700, 1800, and 1900 were not leap years. Read the article. -- Elphion (talk) 02:31, 11 January 2016 (UTC)

I think that by "To not overcomplicate things" he means for testing the current year, during our lifetimes. Or maybe he's trying to set up the year-2100 bug for his great-grandchildren. Dicklyon (talk) 03:37, 11 January 2016 (UTC)

Perhaps, but deliberate coding errors for expedience can backfire. You don't know where your library will get used. I once worked on a study involving analysis of local newspaper accounts of labor unrest in northern England around the turn of the 19th century, and we were blindsided by software that didn't realize 1800 was not a leap year. -- Elphion (talk) 00:29, 12 January 2016 (UTC)

Vernal equinox year ≠ mean tropical year

This edit by [User:156.61.250.250]] asserts "Averaged over the long term, the vernal equinox year is equal to the mean tropical year, which is the same as the time between successive mean vernal equinoxes." But as our article Tropical year and the numerous sources cited in that article make clear, a mean tropical year is not the same as the time between successive mean vernal equinoxes (if indeed the term "mean vernal equinoxes" is even defined by the astronomical community. One highly authoritative source, the The Astronomical Almanac Online! (Glossary) does not define "mean tropical year" but defines "year, tropical" as

the period of time for the ecliptic longitude of the Sun to increase 360 degrees. Since the Sun's ecliptic longitude is measure with respect to the equinox, the tropical year comprises a complete cycle of seasons, and its length is approximated in the long term by the civil (Gregorian) calendar. The mean tropical year is approximately 365 days, 5 hours, 48 minutes, 45 seconds.

This is clearly different from "time between successive mean vernal equinoxes."

Even if some plausible explanation could be contrived to show the statement is true for some interpretation of "mean" and some interpretation of "averaged over the long term" it is not helpful to include a claim that is not supported by a reliable source and uses language differently from how it is used by the astronomical community. Jc3s5h (talk) 14:47, 2 March 2015 (UTC)

The mean tropical year is the average of all the years obtained by starting the year from each and every point of the earth's orbit round the sun. So how can that be different from the long term mean interval between both equinoxes and both solstices?156.61.250.250 (talk) 15:09, 2 March 2015 (UTC)

156.61.250.250 -- Over very long periods (tens of thousands of years) they will average out the same, but right now the specific interval between two vernal equinoxes is not quite the same as the average amount of time it takes the sun to go 360° from the point of view of the earth, due to various subtle effects (see Milankovitch cycles etc.)... AnonMoos (talk) 20:04, 2 March 2015 (UTC)

--- Also over very long periods (tens of thousands of years) the average amount time in days it takes the sun to go 360° from the point of view of the earth would decrease significantly. Karl (talk) 12:50, 3 March 2015 (UTC)

The glossary defines "mean equinox" as follows:

mean equinox and equator: the celestial reference system determined by ignoring small variations of short period in the motions of the celestial equator and ecliptic. Thus the mean equinox and equator are affected only by precession. Positions in star catalogs are normally referred to the mean catalog equinox and equator of the beginning of a Besselian year.

The problem with terms like "vernal equinox year" and "(mean) time interval between two successive spring equinoxes" is that these terms are not defined. This is an encyclopaedia, and our mission is to define terms for the benefit of our readers. 156.61.250.250 (talk) 11:44, 7 March 2015 (UTC)

After looking at the history of the article, I see that terms relating to the vernal equinox year have been in the article since 26 November 2001. This article has been degraded over the years by removing some statements from the accuracy discussion, while leaving others behind. The result is incoherent. Since Gregorian calendar already has a discussion of the issue that is much better than what is currently in this article, I have modified this article to refer to Gregorian calendar#Accuracy for details. Jc3s5h (talk) 17:49, 7 March 2015 (UTC)

There seems to be a lot of confusion over this. I thought that the definition of tropical year was the mean measured over equinoxes and solstices, but one article implies that it has been redefined? In any case, we need to specify the epoch in the definition because the length is changing significantly over hundreds of years. Dbfirs 14:06, 9 March 2015 (UTC)

... later ... Thanks, Jc3s5h, for the correction. The "(mean) time interval between two successive spring equinoxes" has been measured accurately for hundreds of years, and the Gregorian calendar was based on this measurement, but it is different from what is currently defined as the (mean) tropical year. Dbfirs 14:25, 9 March 2015 (UTC)

I feel I should apologize for my part in the confusion. In the past I made some changes to this article to try to improve certain phrases, but I really should have looked a the section as a whole. I should have realized earlier the section was inadequate and either needed to reiterate, at length, material from "Gregorian calendar", or refer those issues to "Gregorian calendar". Jc3s5h (talk) 15:21, 9 March 2015 (UTC)

---

P.S. See File:CompareTropicalYears.png for a visual graph... AnonMoos (talk) 16:11, 19 July 2015 (UTC)

Thanks for that interesting graph. It's appropriate to note that the Gregorian formula will match the vernal equinox year remarkably closely between 3000 and 6000 AD, though Christopher Clavius could not have known this at the time. It seems that we will not need to think about a correction (assuming that we still retain the Gregorian objective) until about 7000 AD. (See Jc3s5h's important point below.) Dbfirs 20:31, 26 August 2015 (UTC)

I don't think the graph means what you think it means. It claims to be based on a book by Jean Meeus. I don't have the book in question, but I have a similar one by him, Astronomical Algorithms. I believe the graph is giving year length in days of 86,400 SI seconds. That's because the calculations are much easier in SI seconds, and the length of seconds of mean solar time cannot be accurately predicted. The Gregorian calendar has always counted actual solar days; the switch from apparent solar time to mean solar time may have changed the exact time the new year begins, but did not change the mean length of the calendar day. The midpoint of the time span mentioned by Dbfirs is 4500 AD. The last time the length of the mean solar day was exactly 86400 SI seconds was in about 1900. Each century the length of the mean solar day, measured in SI seconds, increases about 1.7 ms. After 26 centuries the length of the day will be about 86400.0442. That's a ratio of 0.999999488, so the value on the graph of 365.2425 SI based days is about 365.2423 mean solar days.

In November the ITU will once again decide whether to drop leap seconds. If they do, it will no longer be obvious whether the Gregorian calendar keeps SI days or solar days, and most of our time and calendar articles will require revision. Jc3s5h (talk) 22:28, 26 August 2015 (UTC)

Thanks for pointing out that important distinction. If we drop leap seconds and maintain our current time zones with no "leap hours", will this eventually lead to sunset at midnight? Dbfirs 07:35, 27 August 2015 (UTC)

Yes. Also, the accumulation of error is non-linear, so it would happen much sooner than you would think from a linear extrapolation, but would still be many thousands of years. Of course, keeping leap seconds isn't a solution in the very long term; eventually you would need multiple leap seconds per day. Jc3s5h (talk) 12:07, 27 August 2015 (UTC)

At present, the leap second seems the logical option to avoid noon drift, but if computer programmers get their way, or when leap seconds become too frequent, we'll drop them and maybe instead introduce leap hours by omitting the "spring forward" adjustment in occasional years -- at least this seems to be the most socially acceptable option. Of course, by the time a leap hour is needed, there might be no civilised society to bother about such adjustments. Is there an equation anywhere for the quadratic increase in delta t? Dbfirs 16:37, 27 August 2015 (UTC)

Archive old discussions?

Is there any objection if I set up automatic archiving of old discussions? Jc3s5h (talk) 14:45, 22 March 2015 (UTC)

What citation format?

What citation format would people prefer for this article? If it were left to me, I would use the {{Citation}} format since most sources are only mentioned once or twice, so there is no need to set up short citations plus a bibliography. The first citation used APA style and was just an general reference, not an inline citation. Jc3s5h (talk) 14:45, 22 March 2015 (UTC)

Done Jc3s5h (talk) 23:19, 18 April 2015 (UTC)

section Algorithm: adding Excel example

Algorithm

The following pseudocode determines whether a year is a leap year or a common year in the Gregorian calendar (and in the proleptic Gregorian calendar before 1582). The year variable being tested is the integer representing the number of the year in the Gregorian calendar, and the tests are arranged to dispatch the most common cases first. Care should be taken in translating mathematical integer divisibility into specific programming languages.

if (year is not exactly divisible by 4) then (it is a common year)
else
if (year is not exactly divisible by 100) then (it is a leap year)
else
if (year is not exactly divisible by 400) then (it is a common year)
else (it is a leap year)

Excel

This algorithm translates into Excel like this, whereas year stands for the cell which refers to the input cell:

=IF(NOT((year/4=TRUNC(year/4)));"common year";IF(NOT((year/100=TRUNC(year/100)));"leap year";IF(NOT((year/400=TRUNC(year/400)));"common year";"leap year")))
or reversed, more simplified:
=IF((year/400=TRUNC(year/400));"leap year";IF((year/100=TRUNC(year/100));"common year";IF((year/4=TRUNC(year/4));"leap year";"common year"))

-- 23:17, 20 August 2015 31.151.83.20

Fine, but an Excel formula is not the sort of thing WP would ordinarily supply. The shape of the algorithm in pseudo-code is appropriate, but translations into specific languages generally not. -- Elphion (talk) 17:51, 26 August 2015 (UTC)

National variety of English

The first edit I can find that contains a word spelled differently in British and American English is here; it is from 2006. Based on this, I think the spelling in this article should be British. Comments? Jc3s5h (talk) 15:13, 22 August 2015 (UTC)

Yes, I think you are correct, but it's probably not worth arguing over since the "z" spelling is still sometimes used in British English (just not taught any more). Dbfirs 16:32, 22 August 2015 (UTC)

It's not a matter of arguing about it. It would be helpful to place the {{British English}} template on the talk page so future editors who are about to write a word that depends on the national variety can easily figure out which spelling to use without searching through the article trying to find words that are sensitive to the national variety. Jc3s5h (talk) 00:55, 23 August 2015 (UTC)

In that case, I agree. Dbfirs 06:40, 23 August 2015 (UTC)

I have marked the article as using British English. It turns out my Firefox British English dictionary accepts "synchronized" so I did not need to edit the article. Jc3s5h (talk) 12:27, 23 August 2015 (UTC)

British English with "-ize" spellings is so-called Oxford spelling... AnonMoos (talk) 14:23, 26 August 2015 (UTC)

Yes, the OED gives both spellings, but the "-ize" is the main entry. I suppose the ultimate etymology is Greek, but the word didn't come directly from that language, so the argument for "z" is weak. The earliest cite in the OED (1624) uses the "s" spelling, as do most modern British writers. The point that Jc3s5h correctly made is that the "s" spelling establishes British English. Dbfirs 19:58, 26 August 2015 (UTC)

Proper algorithm

if ((year is divisible by 400) or ((year is divisible by 4) and (year is not divisible by 100))) then (leap year)
else (common year)

in C:

bool isLeapYear(int year)
{
    return year % 400 == 0 || year % 4 == 0 && year % 100 != 0;
}

— Preceding unsigned comment added by 77.239.254.82 (talk) 20:32, 3 September 2015

"Proper" is in the eye of the beholder. The point of the version in the article is that only one division is performed for almost all common years, and only two for most leap years. The version above is more expensive. -- Elphion (talk) 21:30, 3 September 2015 (UTC)

In the version in the article, surely if "year" is not exactly divisible by 100 it won't be divisible by 400 either, so the third "if" will never be satisfied? MarkGeater (talk) 03:43, 30 October 2015 (UTC)

If the test (is not divisible by 100) succeeds, the algorithm terminates (at that point, we know it's divisible by 4 but not 100, so it is an ordinary leap year). But if the test fails (i.e., the year is divisible by 100), then we have to test whether it's also divisible by 400. -- Elphion (talk) 06:24, 30 October 2015 (UTC)

Then just move the 400 test to the end.

bool isLeapYear(int year)
{
    return  year % 4 == 0 && year % 100 != 0 || year % 400 == 0;
}

87.102.44.18 (talk) 12:05, 6 March 2016 (UTC)

In C#:

// Gregorian.isLeapYear(year) will return TRUE for any year in the set { 0 < year < 3200 }
// Calculations: (year % 100) > 0 — if the year is not a century (year % 4) will equal 0 only for leap years
//    otherwise: (year % 400) — evaluates to a non-zero value for all years not divisible by 400
// Derives a Boolean result using only one conditional/test, one comparison and two calculations.
public class Gregorian 
{ 
    public static bool isLeapYear(int year) { return (year % ((year % 100)>0 ? 4 : 400)) == 0; }
}

— 216.240.6.210 (talk) 01:51, 20 March 2016 (EDT)

"Most efficient" leap year test:

See: http://stackoverflow.com/questions/3220163/how-to-find-leap-year-programatically-in-c/11595914#11595914

This code is valid in C, C++, C#, Java, and many other C-like languages. This "most efficient" code below replaces costly modulo (division) operations with bit-wise logical AND operations, and terminates after only ONE operation for three-quarters of all cases. The costly division (modulo 25) for the 100th year test only executes for "4th year" cases:

// Most efficient leap year test
// See: http://stackoverflow.com/questions/3220163/how-to-find-leap-year-programatically-in-c/11595914#11595914
if ((year & 3) == 0 && ((year % 25) != 0 || (year & 15) == 0))
{
    /* leap year */
}

— Kriceslo (Kriceslo) 12:29, 23 November 2016 (UTC)

The current algorithm is very hard to understand. I suggest to change it to the following:

 if (year is divisible by 400) then (it is a leap year)
 else if (year is divisible by 100) then (it is a common year)
 else if (year is divisible by 4) then (it is a leap year)
 else (it is a common year)

— Preceding unsigned comment added by Dennislixin (talk • contribs) 03:06, 7 March 2016 (UTC)

What both of the previous suggestions overlook is the arrangement of the tests to handle the most frequent cases first for efficiency. The second proposal is in fact just the reverse of the algorithm in the article, so hardly any more or less difficult to understand. -- Elphion (talk) 04:00, 7 March 2016 (UTC)

In asymptotic terms, this is clearly inconsequential (it runs in constant time no matter what).--Jasper Deng (talk) 05:06, 11 March 2016 (UTC)

Nonsense. A test like this gets used constantly. Small savings even in O(1) algorithms add up. -- Elphion (talk) 07:53, 11 March 2016 (UTC)

Who says I always have to give the best case inputs? What if, for some reason, my program only calls the algorithm as a black box on years that require the worst-case amount of computations? In any case, reader clarity is more important than efficiency for the pseudocode, so I would not dismiss any suggestion just due to efficiency.--Jasper Deng (talk) 08:18, 11 March 2016 (UTC)

This is a case where the order of the tests makes a significant difference for the expected input (and yes, one expects common and non-century years to dominate the input, despite artificial scenarios), so it makes sense to reflect that in the pseudocode. Your argument amounts to accepting bubble sort as the premiere sorting algorithm because its pseudocode is easy to understand. -- Elphion (talk) 16:09, 11 March 2016 (UTC)

No it does not. In that case, bubble sort is asymptotically slower then optimal. This is not the case here.--Jasper Deng (talk) 16:26, 11 March 2016 (UTC)

The asymptotic behavior of the leap year algorithm is completely irrelevant (all versions are O(1)); the over-all performance is not. The point I am making is that the "readability" of the pseudocode should not hide that (as the pseudocode for Bubble Sort hides a significant performance liability). -- Elphion (talk) 16:47, 11 March 2016 (UTC)

Doing it the hard way

It is surprising the article doesn't simply start by pointing out that the tropical or solar year is around 365.2422 days long currently, thus to keep the calendar year aligned with it (so the seasons don't drift, etc.), one needs to add about a day every four years. If you want to get fancy, since .25 isn't quite the same as .2422 (or thereabouts), you can improve the correction by observing or not observing leap years at the years divisible by 100 or 400 as needed. Starting with the length of the tropical year (365.2421... days) makes the explanation of leap years a lot easier than the rather vague statement that this article starts with: "Because seasons and astronomical events do not repeat in a whole number of days, calendars that have the same number of days in each year drift over time with respect to the event that the year is supposed to track." — Preceding unsigned comment added by 192.158.48.16 (talk) 12:07, 29 February 2016 (UTC)

The aim of the Gregorian system was to keep the northward equinox as close as possible to March 21st without ever being later than that date. In the current epoch (around the year 2000), northward equinoxes occur on average every 365.24237 days. Thus the Gregorian calendar is maybe more accurate than its creators realised, since they didn't have modern accuracy. Your figure of 365.2422 days for the mean tropical year is averaged over equinoxes and solstices, or is the long-term average over a cycle of more than 23000 years. See our article on year for the details. Dbfirs 12:41, 29 February 2016 (UTC)

Algorithm?

Wikipedia is not a database of code, and I do not see why there needs to be pseudocode to figure out if year X is a leap year. "Some exceptions to this basic rule are required since the duration of a tropical year is slightly less than 365.25 days ... The Gregorian calendar therefore removes three leap days every 400 years, which is the length of its leap cycle. This is done by removing February 29 in the three century years (multiples of 100) that cannot be exactly divided by 400." is clear enough. Perhaps move it to Wikibooks for some programming tutorial, but it was indiscriminately placed. Esquivalience ^t 21:33, 29 February 2016 (UTC)

Are you referring to the very short Leap year#Algorithm? Or to some recent edits? Something else? If the first, of course the basic algorithm should be retained in the article—why should an encyclopedic article chatter about all the details and omit the method used to determine the basic result? Johnuniq (talk) 21:49, 29 February 2016 (UTC)

I wholeheartedly agree. Given the number of programmers who loudly proclaimed that 2000 was not a leap-year, the algorithm is a valuable antidote. -- Elphion (talk) 21:57, 29 February 2016 (UTC)

In this edit, I just added a statement about how Neil deGrasse Tyson described this algorithm in words. Source video is posted in the reference.
What NdT did not address is how the calendar is driven by cycles of the Sun & Moon with the Earth's rotation & revolution. It is a "cosmic coincidence" that the Sun & Moon have the same apparent size to us. This is because the size-distance ratio of the Sun & Moon is 400. The Sun is 400 times the diameter of the Moon, and the Sun is 400 times the distance of the Moon. Result: Same apparent size.
If NdT had wanted to present more intriguing facts, he would have pointed out this further "cosmic coincidence" in the similarity to the Leap Year rule: 4 x 100 = 400.
There is a similar pattern in the relationship between the Sun-Moon-Earth in space as well as time.--Tdadamemd sioz (talk) 22:55, 29 February 2016 (UTC)

...and to give one more layer of connection, NdT could also have explained the similarity in the rotation period of the Sun with the orbit period of the Moon: both are 27 days.--Tdadamemd sioz (talk) 00:10, 1 March 2016 (UTC)

I am referring to Leap year#Algorithm. The pseudocode itself may be an appropriate way to cover the basic definition of a leap year, but advising beginner programmers on how to implement this algorithm is inappropriate for a general topic. It would be better to logically explain the simple method, like so:

Imparts more information in about the same length as the current section. Esquivalience ^t 00:52, 1 March 2016 (UTC)

That says roughly the same thing in less precise terms, and I find it more confusing. It does not handle years that are not divisible by 4, for example, and by the time you've added that in, it's no less complex than the current pseudo-code -- and more prone to error when converted into actual code. -- Elphion (talk) 01:17, 1 March 2016 (UTC)

Hmmm, I just took a closer look and I agree that the wording needs to be cleaned. The purported advice should be removed (apart from its lack of relevance here, if someone doesn't know to worry about integer divisibility, a bit of text here won't help). There is no need to fill space by mentioning pseudocode or which are the most common cases (again, if a programmer can't work that out, they need to stop programming). The "famed astrophysicist" text needs to be removed—the language is unencyclopedic and the text is unnecessary. However, I think I prefer the current wording of the algorithm because it is understandable and unambiguous. The text in the box above is very fine but the "except" is only parsable if the reader already knows the algorithm. Johnuniq (talk) 01:22, 1 March 2016 (UTC)

Leap second should not be covered in this article

The following paragraph was recently added to the lead of this article:

The same type of problem happens in the relationship between the day and the number of seconds in the day: If you divide the larger measure of time by the smaller, you do not get a whole number. Instead, the result is an unending decimal. There is no way to perfectly fit a whole number of seconds into a day, nor is there a way to perfectly fit a whole number of days/months into a year. As leap years are used to correct calendar drift, the resulting drift in measuring the diurnal cycle is corrected by the use of leap seconds.

Since there is no language further describing the meaning of this paragraph, it must understood in the context of this article, which is various calendars that have existed for the last few millennia. Leap seconds are not really comparable to leap days. In the calendars that use them, including the Gregorian calendar which is the world-wide standard for international commerce, everybody observes the leap day on the required day. For leap seconds, on the other hand, only a minuscule proportion of time keeping devices are even capable of representing a leap second; most people don't even worry about it and just treat it as one more source of error that gets corrected the next time their time-keeping device is reset.

Among those who do care about each and every second are astronomers. They have a wide variety of time scales to choose from, such as Coordinated Universal Time (UTC), UT1, Terrestrial Time, and International Atomic Time. Of these, only UTC observes leap seconds.

What about the law? Although the "official" time broadcasts or other "official" sources of time in virtually every country contain leap seconds, this has not been recognized by the law in the US until 2007 (see America COMPETES Act). The UK and Canada have still not passed laws to switch from mean solar time to UTC. (See http://www.publications.parliament.uk/pa/ld199798/ldhansrd/vo970611/text/70611-10.htm ).

These complexities are too much to cover in this article, so leap seconds should not be covered in this article. Jc3s5h (talk) 23:41, 29 February 2016 (UTC)

No one is suggesting that the complexities be covered. What that edit does is explain the similarity in the generality of both situations. To not mention it would be to compartmentalize. And that would go against the spirit of what the role of an encyclopedia is: to explain how things are related.--Tdadamemd sioz (talk) 00:06, 1 March 2016 (UTC)

This article must mention leap second somewhere, with a link to more information. However, such a mention most definitely should not be in the lead, see WP:LEAD. This article is about leap years which are needed for real-world reasons, whereas leap seconds are an esoteric detail. The mention of leap seconds that should be in this article should be very brief. Johnuniq (talk) 00:16, 1 March 2016 (UTC)

The paragraph is false. Leap seconds have not been observed at all as recently as 1971. "There is no way to perfectly fit a whole number of seconds into a day" is clearly false, because the ITU is seriously considering doing exactly that by just dropping leap seconds, thus redefining the day so that mean UTC noon is no longer tied to Greenwich. Putting in all the caveats would make the paragraph too complicated for this article, and particularly inappropriate for the lead. Jc3s5h (talk) 00:18, 1 March 2016 (UTC)

You said:

"...is clearly false"

Au contraire. I see my statement to be perfectly accurate. I said there is no way to have a perfect fit.

What the ITU has tabled is a proposal that constitutes an imperfect fit. If you throw away the leap second, then the diurnal cycle will no longer remain synchronized to the clock. It will drift, and that drift will accumulate. By a similar token, you can have a calendar that throws away the leap year. That too would be an imperfect fit, and the result will be a calendar that drifts, with that drift accumulating as well.

"There is no way to perfectly fit a whole number of..."

This phrase identifies the problem that is common to the solution of both leap years and leap seconds.--Tdadamemd sioz (talk) 03:17, 1 March 2016 (UTC)

@Tdadamemd sioz: Furthermore, as I noted on your talk page, it is flat-out wrong to imply that all numbers with infinite decimal expansions are irrational. If consensus ever comes in favor of content like this, then at the very least, the math has to be right.--Jasper Deng (talk) 00:23, 1 March 2016 (UTC)

It would certainly be more accurate to say "unending, non-repeating decimal", instead of the words I chose. I would agree with criticism that to simplify to the point of inaccuracy is an over-simplification, and has the potential to cause more harm than benefit.--Tdadamemd sioz (talk) 03:17, 1 March 2016 (UTC)

@Tdadamemd sioz: It's more that we should not be linking to the article on irrational numbers when the quotient definitely need not be irrational.--Jasper Deng (talk) 07:01, 1 March 2016 (UTC)

The numbers in question are neither irrational nor repeating decimals; they are experimental results which have a finite accuracy depending on the reliability of the methods used to measure the experimental results. Jc3s5h (talk) 13:03, 1 March 2016 (UTC)

Jc3s5h, this statement of yours needs a specific rebuttal:

"Leap seconds are not really comparable to leap days. In the calendars that use them, including the Gregorian calendar which is the world-wide standard for international commerce, everybody observes the leap day on the required day. For leap seconds, on the other hand, only a minuscule proportion of time keeping devices are even capable of representing a leap second; most people don't even worry about it and just treat it as one more source of error that gets corrected the next time their time-keeping device is reset."

You may not care about 1 second. But computers care. Airplanes care. Self-driving cars care. Navigation these days happens via speed of light signals. That's 300,000 kilometers-per-1-second. The previous section here is a discussion about computer algorithms. Code is likewise written to implement leap seconds. So you say you don't care, but if the website you're trying to access crashes because of poorly written code, you might start to care. And that's to say nothing of an airplane or car that you're riding in.--Tdadamemd sioz (talk) 04:19, 1 March 2016 (UTC)

I have no problem with mentioning and linking to leap seconds. But they are fundamentally a different phenomenon than leap days. Leap days arise because the number of days in a year is not a whole number, but the difference is (for practical purposes) a predictable value that can be accommodated with an algorithm for deciding when to insert a leap day. Leap seconds, on the other hand, arise because the earth's rotation varies unpredictably (due principally to random changes in the distribution of its mass), and are inserted only experimentally when more accurate timepieces get out of whack with the earth. It's not that the day has a fractional number of seconds, it's that the number varies significantly over time. -- Elphion (talk) 13:36, 1 March 2016 (UTC)

Moreover, the putative irrationality of the quotient is a complete red herring. The precise value (either for leap days or leap seconds) is not known precisely enough to determine whether it is irrational; and in any case, both quotients vary over time (though in the case of leap days not enough to affect the algorithm for thousands of years). -- Elphion (talk) 18:00, 1 March 2016 (UTC)

To try to move things along, I propose the following replacement for the last paragraph in the lead.

-- Elphion (talk) 17:52, 2 March 2016 (UTC)

I'd support that addition, especially as this lengthening of the day will have an impact on the formula for leap years in the far future. Dbfirs 18:05, 2 March 2016 (UTC)

The above suggestion is definitely better than the current paragraph. ----Ehrenkater (talk) 18:09, 2 March 2016 (UTC)

And we can say that explicitly: "In several thousand years, the change in the length of the day will have accumulated enough to affect the accuracy of the Gregorian leap year rule." -- Elphion (talk) 18:21, 2 March 2016 (UTC)

I suppose the brief paragraph suggested by Elphion might be useful to readers who are wondering about how or if leap seconds relate to leap years. But the article already contains this sentence:

The "Accuracy" section of the "Gregorian calendar" article discusses how well the Gregorian calendar achieves this design goal, and how well it approximates the tropical year.

I think it is unwise to repeat detailed information about the accuracy of the Gregorian calendar in this article; the usual result of such duplication is that the two separate versions get edited over a period of time and end up contradicting each other. Jc3s5h (talk) 19:20, 2 March 2016 (UTC)

I don't see a problem mentioning this is in the lead as well as in the body. And "several thousand years" is not very detailed. Gregorian calendar#Accuracy, after all, says almost exactly the same thing: "On time scales of thousands of years, the Gregorian calendar falls behind the astronomical seasons because the slowing down of the Earth's rotation makes each day slightly longer over time (see tidal acceleration and leap second) while the year maintains a more uniform duration." -- Elphion (talk) 20:17, 2 March 2016 (UTC)

I think the fact that the lengthening of the day will eventually affect the Gregorian rule is, as Dbfirs suggests, exactly the point of connection needed here. -- Elphion (talk) 20:21, 2 March 2016 (UTC)

OK, here's a revised proposal:

-- Elphion (talk) 21:49, 3 March 2016 (UTC)

This article is about the general concept of a leap year, not just the Gregorian calendar. The effect of leap seconds is equally important to all the arithmetic calendars that are good approximations to tropical years, vernal equinox years, or whatever astronomical year the calendar was designed to approximate. The paragraph suggested by Elphion doesn't belong in the lead, and shouldn't be confined to the Gregorian calendar. Which calendars should be connected to leap seconds depends on whether the users of said calendars normally use times of day that are defined offsets from UTC in conjunction with their calendar. Jc3s5h (talk) 22:26, 3 March 2016 (UTC)

@Jc3s5h: Clarify, please. Do you think that the first paragraph of the suggested text (or any reference to leap-seconds) is inappropriate for the lead? This is the obvious place to point interested readers to Leap second, even if we omit direct reference to the Gregorian calendar. -- Elphion (talk) 17:06, 11 March 2016 (UTC)

I think the first paragraph of the latest proposal could go in the lead. Jc3s5h (talk) 18:51, 11 March 2016 (UTC)

OK, I'll add that to the lead. -- Elphion (talk) 17:09, 12 March 2016 (UTC)

What is the term for 'leap year eve' when not a leap year, or February 27 rather 28 in a common year?

Certainly there must be a traditional term for a common year's missing (or lack of) a Leap Year Eve.

Dlf1wayout (talk) 07:56, 28 February 2017 (UTC) Dlf1wayout a.k.a. LSDexitOzAmericaDotOrg

Why must there be a traditional term for a day that is not traditionally celebrated? Do you know of some culture that does celebrate this day? Even in a leap year, there are very few celebrations of "leap year eve". Dbfirs 12:33, 28 February 2017 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Leap year. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20100115082230/http://www.thesomnambulist.org/2008/12/galileo-day-campaign-29-february-2012/ to http://www.thesomnambulist.org/2008/12/galileo-day-campaign-29-february-2012/

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 16:16, 4 June 2017 (UTC)

Semi-protected edit request on 20 June 2017

Pls include "List of leap years (till 3004)" article at "See also" section. Thanks 86.59.211.222 (talk) 02:08, 20 June 2017 (UTC)

Not done. The list was nominated for deletion in 2013 and the decision was to delete it. I concur with that decision and reverted 86.59.211.222's attempt to restore it. Jc3s5h (talk) 04:05, 20 June 2017 (UTC)

flaw with leap year algorithm

The leap algorithm only applies to 1752 and onwards.

This means 1700 has 366 days even though by definition it is not a leap year.

Check it for your self. I propose editing the main article to reflect this. — Preceding unsigned comment added by 110.174.28.45 (talk) 01:59, 18 March 2018 (UTC)

What? The Gregorian calendar was introduced in 1582, but was not adopted by all countries at the same time. England and most of the British Empire adopted the Gregorian calendar in 1752. Whether England was using the calendar in 1700 does not change the calendar.

And 1700 was a leap year for countries using the Gregorian calendar. It also was for countries using the Julian calendar (but that's irrelevant). Did you mean 1600? That wasn't a leap year for the Gregorian calendar but it was for the Julian calendar. Meters (talk) 02:20, 18 March 2018 (UTC)

1600 was a leap year in the Gregorian calendar. 1700 was not. (Both were leap years in the Julian calendar.) -- Elphion (talk) 04:01, 18 March 2018 (UTC)

Yes, of course. My apologies. I had it backwards. I know better but rather than thinking I looked at that hideous pseudocode we use. Why is it that we think it's a good idea to use a confusing pseudocode just because that's an efficient way of programming it? I don't think it adds anything useful to the article. Meters (talk) 05:46, 19 March 2018 (UTC)

This wiki article says "For example, the years 1700, 1800, and 1900 were not leap years, but the years 1600 and 2000 were." And if you check the year 1700 has 366 days (i.e. has Feb 29). So the algorithm fails for 1700. But from 1800 it is correct. Since 1752 was the year that Gregorian Calendar was adopted by the British Empire, this means the algorithm only applies to 1752 onwards. Hence this wiki article is not fully correct. If you look around the internet you will see the same "misinformation". I think we should try to make it a bit more correct. — Preceding unsigned comment added by 110.174.28.45 (talk) 06:18, 18 March 2018 (UTC)

That statement is in the section Leap year#Gregorian calendar, where it is correct. You could perhaps add a subsection at the end of that section to say when various countries adopted that calendar, and note that 1700 was a leap year in those that had not adopted it by then. Dicklyon (talk) 06:51, 18 March 2018 (UTC)

The recent addition by 110.174.28.45 is not sufficiently clear to explain the confusion. I've removed it and added a single sentence under the algorithm. Please improve it. Dbfirs 08:10, 18 March 2018 (UTC)

The single line covers it. All Good =) --110.174.28.45 (talk) 09:33, 18 March 2018 (UTC)

I still have concerns about giving 1700 as an example, but I guess we will just have to live with it.--110.174.28.45 (talk) 09:35, 18 March 2018 (UTC)

Okay, so after some more thoughts, here are my conclusions:

• The Algorithm is valid regardless of year
• The attempt to use the result of the algorithm for determining number of days in the year is invalid for years before 1752

See the following example:

Year	Leap or Not Leap according to Algorithm	Number of days inferred from leap or not leap	Actual number of days in the year
1300	Not Leap	365	366
1400	Not Leap	365	366
1500	Not Leap	365	366
1600	Leap	366	366
1700	Not Leap	365	366
1800	Not Leap	365	365
1900	Not Leap	365	365
2000	Leap	366	366

From that perspective, we could say algorithm result for all years >1700 (not including 1700) can be used to infer number of days in the year.

--110.174.28.45 (talk) 11:09, 18 March 2018 (UTC)

I think you are confused. Leap years always have 366 days. Normal years have 365 days always. You are confusing the Julian calendar actually used before 1582 with the proleptic Gregorian calendar before 1582 (or 1752). Dbfirs 12:27, 18 March 2018 (UTC)

RfC: use "peer-reviewed" in connection with stackoverflow.com

Should the phrase "peer-reviewed" be used in connection with stackoverflow in a way that suggests stackoverflow.com contributions are peer reviewed? In particular see this recent edit. Jc3s5h (talk) 22:44, 9 December 2018 (UTC)

(Comment by author of edit in question: Not every contribution to Stack Overflow is purported to be "peer-reviewed". At issue, is Verifiability and Reliability: "Base articles on reliable, third-party, published sources with a reputation for fact-checking and accuracy." Stack Overflow CAN BE such a source. Over many years, heavily up-voted and moderator-scrunitized contributions to Stack Overflow certainly do gain legitimate peer-review. From Peer review: "Peer review requires a community of experts in a given (and often narrowly defined) field, who are qualified and able to perform reasonably impartial review." Stack Overflow is such a community of experts and its voting and moderation scheme ensures the highest-quality contributions are vetted. Rigorous Scholarly peer review should not be confused with or cited as a tool to detract from legitimate, "Verifiable" and "Reliable" peer-reviewed sources.) —Kriceslo (talk) 10:04, 10 December 2018 (UTC)

• No. Code on Stack Overflow is self-published user-generated content. While comments from participants on an online forum may technically fall under "peer review", the term peer-reviewed often refers to scholarly peer review and should not be used in a case where it falsely implies that self-published content has passed rigorous validation. — Newslinger talk 23:40, 9 December 2018 (UTC)
  • Regarding this particular case, external links do not belong in the article body (WP:EL), and should be removed. — Newslinger talk 09:29, 10 December 2018 (UTC)
  • RESPONSE: I would tend to agree (in part) with User:Newslinger, with the caveat that a programming example should be provided next to the textual algorithm and the external link should be a citation supporting the programming example. The algorithm is heavily cited by many programmers and it is a valuable contribution to the encyclopedia to provide a simple programming example. —Kriceslo (talk) 09:37, 10 December 2018 (UTC)
• Not the first time. The same editor cited the same stackoverflow post about the same time the post appeared on stackoverflow, in 2012. Jc3s5h (talk) 23:50, 9 December 2018 (UTC)
  • RESPONSE: Correct. In 2012 I didn't label it such, but in six years it has received numerous peer votes and awards (see my comment, infra.) Kriceslo (talk) 08:29, 10 December 2018 (UTC)
• Clearly not, "peer review" will be interpreted by the reader as meaning that it has been reviewed by experts, such as academics in the relevant field. Stack overflow code is only reviewed by people who contribute to stack overflow, who are ultimately random people on the internet. It doesn't meet our reliability standards. I don't think there's any value in the objection raised in that edit, as it's far easier to verify that the algorithm given is correct than the alternative, and the efficiency gain is negligible in a typical application. Hut 8.5 23:55, 9 December 2018 (UTC)
• No Stack Overflow is written by volunteers, including reviewers. While some are highly skilled, many ... are not. --GRuban (talk) 01:35, 10 December 2018 (UTC)
  • RESPONSE: WP is written by volunteers. SO implements a peer-review voting system which is credible and highly reliable. Kriceslo (talk) 08:07, 10 December 2018 (UTC)
• No obviously. Johnuniq (talk) 04:03, 10 December 2018 (UTC)
  • RESPONSE: This is a fallacious argument [1] I'd appreciate a rationale. Kriceslo (talk) 08:03, 10 December 2018 (UTC)
• Silly. We can find actual sources for the algorithm instead. Dicklyon (talk) 04:21, 10 December 2018 (UTC)
• In context, the edit is not referring to scholarly peer-review, and is probably fine -- but it is a bad edit in a not good section. (From the RS noticeboard) The edit is a common suggestion that you should use code that others have looked at, it is not making a reference to peer review. Setting that word aside, however, the sentence does not belong in the encyclopedia, as it is giving incomplete advice about programming technique in an article about the calendar. Putting that sentence aside, I would offer that this section should drop the mission of trying to write good pseudocode that helps the reader program well and instead write good English text that helps the reader understand easily. There are lots of phenomena that could be explained in pseudocode, but that's not how we write the encyclopedia. I'd suggest re-writing it as a rule in English -- like the re-ordering suggested by Dennislixin two years ago, but was shot down because of the programming technique, not the quality of the writing. Chris vLS (talk) 06:06, 10 December 2018 (UTC)

The article already has a clear text explanation, from a highly reliable source: the blockquote in the "Gregorian calendar" section. (It's been there for a long time, but today I cut and pasted it from the Naval Observatory again; some editors don't realize you shouldn't "fix" the grammar of a direct quote.) Jc3s5h (talk) 14:11, 10 December 2018 (UTC)

• Yes (CONDITIONALLY) Each 'No' above is somewhat short-sighted. Stack Overflow is, indeed, user-generated content that is self-published (as is the majority of all content, including WP). However, it is peer-reviewed by members, admin moderators, and experts in the field (not just "random people on the Internet") via a voting scheme, comments, and heavy moderation. Sentiments that "peer review" requires scholarly rigor are misguided. WP defines Peer Review as follows: "Peer review is the evaluation of work by one or more people with similar competences as the producers of the work (peers)." Also, "Peer review requires a community of experts in a given (and often narrowly defined) field, who are qualified and able to perform reasonably impartial review." (From WP at Peer_review#Scholarly) Only members of Stack Overflow may participate in voting and commenting, and members of Stack Overflow are clearly dedicated and interested in programming. S.O. imposes tightly controlled content criteria via moderators and community votes. Indeed, Stack Overflow is more stringently reviewed than WP! While I did post my citation here in 2012, since then it has received 100 "votes" on Stack Overflow and received numerous awards [2] [3] [4] [5] Merely publishing on Stack Overflow does not qualify as "peer review"---it is the very significant number of up-votes by "one or more people with similar competences" that constitutes peer review. This is legitimate peer-review even if some editors confuse scholarly review with the term. Regardless, if substitute language like "community-reviewed" or "expert-reviewed" make everyone more comfortable--I'm fine with that even though both of those are the same thing. MOREOVER, the inline citation is provided in my post as an exempli gratia (e.g.) example. This example does not subtract from the veracity of the containing prose: "Peer-reviewed code () is important... [to avoid leap year bugs]". My concern now, is why all the acrimony over a contribution? And, where is the citation/source/peer-review for the unattributed pseudocode? (which has been outright wrong in past edits) --Kriceslo (talk) 08:29, 10 December 2018 (UTC)
• no Peer review should not and cannot include "members" of an "anyone can join" site. They key should be "qualified", I.E. they have a qualification in the subject they are reviewing. After all a discussion down the pub between two football fans may well be "peer reviewed" (the rest of the pub listing in). "peer review" must mean more then "a group of similarly qualified people", otherwise it just means "a group of people".Slatersteven (talk) 10:52, 10 December 2018 (UTC)

• • RESPONSE: Slatersteven, The very definition of "peer" is ONE OF EQUAL STANDING. It seems feelings about peer review are polluted by false notions. If Peer review didn't include "similarly qualified people" than academics could NEVER attain peer review. Discussions of football in a bar are similarly peer review. Further, I don't believe you have an understanding of Stack Overflow. While it is an "anyone can join" site, it IS NOT an "anyone can comment and review" site (unlike Wikipedia, which literally is ANY random Internet person). Kriceslo (talk) 11:44, 10 December 2018 (UTC)

As a literal interpretation yes, but as I said that just means you can use almost any sources, a group of 8 years old reviewing another 8 year olds work is peer reviewed. And what policy says "Material such as an article, book, monograph, or research paper that has been vetted by the scholarly community is regarded as reliable, where the material has been published in reputable peer-reviewed sources or by well-regarded academic presses.", so no it is not just that it has to be peer reviewed, it must be peer reviewed by reputable sources (after all Wikipedia is "peer reviewed" and it is not an RS).Slatersteven (talk) 11:53, 11 December 2018 (UTC)

• No. We should not use phrasing that creates a stronger impression of stringent quality control than is warranted. Under some circumstances, forum posts can be cited as providing expert opinions. For example, if John C. Baez makes a post about mathematical physics on MathOverflow, it's pretty much like when he makes a post on his own blog: we can treat it as a statement about a topic by a well-established expert on that topic. Even then, the article should be written so that it makes clear that the claim was not vetted in any formal way. XOR'easter (talk) 17:46, 10 December 2018 (UTC)
• No: "peer-reviewing" refers to a process in the scientific community. It is not a sum-of-parts phrase; my proof that 0.999... < 1 is not peer reviewed just because the other kids in my class looked at it and couldn't find a mistake. — Bilorv_(c)(talk) 02:57, 11 December 2018 (UTC)
• No, please. Maybe this helps: User:Guy_Macon/One_against_many. Have a nice day. ~ ToBeFree (talk) 04:13, 11 December 2018 (UTC)
• No. Academic peer review is a very specific procedure. Stackoverflow sites are not subject to academic peer review any more than Wikipedia or Reddit or any other moderated Web 2.0 community. Now, while "peer review" is arguably a broader term than "academic peer review", there's a whole mass of online kooks taking advantage of regular people conflating these meanings, so I don't think we'd be doing a service to our readers by expecting them to understand this nuance. (arrived from RSN) Daß Wölf 11:00, 13 December 2018 (UTC)

RfC Computer Programming Example in Algorithm section?

Should Leap Year page include a computer programming example on how to calculate leap years? The Leap Year page is cited by numerous computer programmers [6] [7] and is used as a reference by programmers for information on how to calculate whether a given year is a Leap Year. Editors of the Leap Year page argue WP:NOTHOWTO (but nevertheless provide a textual algorithm). However, WP:BB argues that providing a real programming example in the very place that is turned to by many programmers makes the encyclopedia better (WP:FATRAT). A single one-line programming example (in the vastly common C programming language) is proposed. —Kriceslo (talk) 09:38, 10 December 2018 (UTC)

• You seem to have one in mind already. Would you make that part of your proposal? Saying where it comes from would be nice too. --GRuban (talk) 15:10, 10 December 2018 (UTC)
  • I wouldn't be opposed to this one-liner from The C Programming Language (Kernighan and Ritchie). --GRuban (talk) 15:21, 10 December 2018 (UTC)
• Yes. I don't think this needs an RfC. It seems like an uncontroversial improvement to the current pseudocode, tagged with {{citation needed}} (and basically duplicated beforehand anyway with a natural language description of the calculation). — Bilorv_(c)(talk) 03:02, 11 December 2018 (UTC)
• Yes, but Comment: If the result of the discussion is "yes", then please take it from a book, not StackOverflow, especially when verifiability appears to be an issue. ~ ToBeFree (talk) 04:24, 11 December 2018 (UTC) (update: changing to neutral comment per arguments below ~ ToBeFree (talk) 04:58, 15 December 2018 (UTC))
• Psuedocode from a book, maybe, otherwise it's either original research or (if it's written in an actual programming language) it's a how to. As a recent arrival to this talk page, I'm kinda stunned to see a debate over whether something in wikipedia should 1) be more understandable to a human reader or 2) have a cleaner, more performant runtime once compiled. It is even more amusing that 2 is winning. This page should be an encyclopedia page for the >99 percent of English speakers who don't speak C or any other programming language. The programming debate should be in an open source project. Or maybe wikicode [8] should be a thing. Chris vLS (talk) 05:48, 12 December 2018 (UTC)

• Agreed, English is preferable to C for the vast majority of readers. That particularly applies to this article which is not "Programming techniques for leap year calculations". There is a style guide (WP:PSEUDOCODE) which says pseudocode is preferable. It says nothing about references. While refs would obviously be good, they are not needed for the simple pseudocode in question due to WP:CALC. Johnuniq (talk) 06:21, 12 December 2018 (UTC)

• Thank you for teaching me something new, Johnuniq, I had no idea we had a style guide for that. I'll take a look. Your point on WP:CALC is well taken, revising my comment above. Chris vLS (talk) 07:27, 14 December 2018 (UTC)

The "style guide" appears to be an essay; a WikiProject advice page, not a part of the Manual of style. We can not refer to it as having any kind of authority. However, the points in this discussion have convinced me to strike my "Yes". ~ ToBeFree (talk) 04:58, 15 December 2018 (UTC)

• We already have (1): see the block text under the section "Gregorian calendar". I suppose it's phrased as a logical condition rather than an algorithm but it's trivial to convert between them. — Bilorv_(c)(talk) 12:27, 16 December 2018 (UTC)

• No code – English-language logic is conventionally used in describing leap year calculation; it's broadly understood, whereas code is not. Dicklyon (talk) 06:54, 12 December 2018 (UTC)
• Any computer code belongs in external links, not in the main text of an English language encyclopaedia. Dbfirs 07:22, 12 December 2018 (UTC)
• No code. Either prose or a list is better than code. Code might not be broadly understood and it will require explanation in prose, which would be unnecessary duplication. (I am not watching this page, so please ping me if you want my attention.) wumbolo ^^^ 22:24, 24 December 2018 (UTC)
• No code not the purpose of the page, I am not sure why we need an Algorithm section anyhow as this should be explained in the prose, it becomes a how to work it out yourself guide where we should be pointing to reliable sources if the reader want to do work it out for themselves. MilborneOne (talk) 11:58, 27 December 2018 (UTC)