Talk:Leap year

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Time (Rated C-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Time, a collaborative effort to improve the coverage of Time on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.
 
This article has been mentioned by a media organization:

New Leap Year Procession[edit]

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[edit]

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)

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!)

— 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[edit]

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)

CompareTropicalYears.png

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?[edit]

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

What citation format?[edit]

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[edit]

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[edit]

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[edit]

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)

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 (talkcontribs) 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[edit]

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?[edit]

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[edit]

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)