Become a fan of Slashdot on Facebook

typodupeerror

## The Math of Leap Days225

The Bad Astronomer writes "We have leap days every four years because the Earth's day and year don't divide evenly. But there's more to it than that... a lot more. A year isn't exactly 365.25 days long, and that leads to needing more complicated math and rules for when we do and don't have a leap year. If you've ever wanted to see that math laid out, now's your chance, and it only comes along every four years. Except every hundred years. Except every four hundred years."
This discussion has been archived. No new comments can be posted.

## The Math of Leap Days

• #### A video with visualisations (Score:3, Informative)

on Wednesday February 29, 2012 @04:34PM (#39201785)
• #### Four days too late! (Score:5, Informative)

on Wednesday February 29, 2012 @04:38PM (#39201831)

The extra, or "bissextile" day is actually inserted immediately after February 23.

The Romans picked up the Egyptians' idea of treating a common year as 360+5 days, since 360 is a highly composite number and all (the Mayans ended up doing the same). But instead of treating the extra 5 days as "epagomenal" (outside any month), they were treated as the last five days before the first month of spring, i. e. the last five days of February.

Treating the five-day block of Feb 24 through Feb 28 as inviolate meant inserting the extra day (previously an extra month) before it.

This is why the Christian feast of Saint Matthias has historically been observed on February 24 in common years and February 25 in leap years; it's always the fifth ("sixth," if you lack an understanding of zero) day before the calends of March.

• #### Re:Complicated? (Score:5, Informative)

on Wednesday February 29, 2012 @05:04PM (#39202153)
bool leap = !(year & 3 || !(year % 100) && year/100 & 3));
• #### Re:Duh. (Score:5, Informative)

on Wednesday February 29, 2012 @05:50PM (#39202649) Homepage

No, the REAL nightmare for programmers is daylight savings time. Especially in the spring, when local times jump back and repeat. Ugh.

• #### Re:Our whole calendar is messed up. (Score:5, Informative)

on Wednesday February 29, 2012 @05:51PM (#39202661)

Our whole calendar is messed up. First- Jan 1st is a poor start date.

I suspect the original pioneers intended the year to start on the Winter Solstice-

Yes, but Julius Caesar decided to start it on the first new moon following. And based on the best data available at the time, every 19th year would have started on a new moon (see below).

which is more like Dec 21st most years on our calendar.

More like Dec 25 at the time, hence the date of Christmas.

So- The year should start on Dec21st.

It took almost 2500 years for everyone to agree to start their year with January (instead of March). George Washington himself was fuzzy on what year he was born. Now, after just getting things straightened out (on a relative time scale), you want to fuck with it again?

Then- our months are supposed to be based on cycles of the moon (Approx every 28 days)-

29.5 days. The usual approximation is alternating months of 29 days and 30 days in length.

but because there were 13 and superstitious nitwits didn't like 13 we have 12 months with varying days.

13-month years work for all the cultures with a lunar calendar, e. g. the Jews and the Chinese. The biggest problem is reckoning when the 13th month gets added. If you treat the tropical year as 365 days, you have to add an extra synodic month 7 times in 19 years (Metonic cycle). If you use 365.25 days for a tropical year, it's more accurate to say that 28 are added in 76 years (Callippic cycle). And if you're using the even-more-accurate 365.2425-day approximation... well, go search for the term "epact."

The whole 7 day week is rather random too-

Try counting the number of days between the first visibility of the new crescent moon and first quarter. Only your eyes and your ability to estimate the illumination of the moon are allowed.

based on some out-of-date dogma that is probably mistranslated. (the original word in Genesis translated as "day" was more accurately "a period of time" although it was often "day" but not necessarily)

If you're referring to chapter 1, note that "day" is always paired with "night."

Let's make a week 10 days- a much more logical number.

Revolutionary France called, they want their "decades" back.

Regardless, (365 mod 7) = 1 while (365 mod 10) = 5.

So we have 36 weeks in a year. If we MUST have a bigger break- we can divide these into 9 months of 4 weeks each.

Even Revolutionary France understood the importance of the four seasons, with agriculture being the foundation of modern civilization and all.

We would then have 5 or 6 days at the end- a "half week"

Coptic Egyptians want their "epagomenal days" back.

Not perfect- but based more on logic than our current system and no-silly formulas needed (other than determining the solstice)

And you would once again have devised a calendar system that focuses on rationalism at the expense of pragmatism and utility, using many ideas have have been tried for centuries or even millennia. Here's what you'd be abandoning:

• 1.) It is currently trivial to determine what day of the week successive years start on.
• 2.) All solstices and equinoxes roughly occur the same number of days before the end of their respective months.
• 3.) Equinoxes and solstices are treated as dates rather than instants (at this instant, it's February 29 in North America and March 1 in Asia).
• 4.) All days are allotted to a month.
• 5.) All days are allotted to a week.
• 6.) Intercalary days follow a simple mathematical pattern with once-in-a-lifetime exceptions.

In fact, 2, 4 and 6 above were deliberate design choices on the part of Julius Caesar specifically to keep things simple.

• #### Revised Julian Calendar (Score:5, Informative)

on Wednesday February 29, 2012 @06:20PM (#39202963) Homepage Journal

And, not everyone has changed to the Gregorian calendar yet.

There's a few areas of European that refused to change from the Julian to the Gregorian, not because of any scientific reason, but because of a political reason. You see for quite a while, the main purpose of a complicated calendar was to keep track of when exactly Easter should be celebrated, and the different Orthodox churches quibbled about this. For a while, there was two different Easters, one for people on the Julian calendar, and one for people using the Gregorian.

The whole world changed to Gregorian, so they had to compromise. The compromise is one of the most hilarious developments in time tracking: the Revised Julian Calendar [wikipedia.org]

Those who follow the Revised Julian Calendar [wikipedia.org] never obey the "every 400 years" rule. Instead, they celebrate leap years every 4, unless the year is divisible by 100, unless the year is mod 900 is 200 or 600

The net result is that those countries were in agreemet with us retroactively in 1600, and in 2000, but the system will fall apart in 2400. The designers then get to live knowing that their principles have not been compromised, yet it will leave the fallout of the difference to their descendants.

• #### I think you're doing it wrong (Score:4, Informative)

on Wednesday February 29, 2012 @06:56PM (#39203315) Journal

You seem to have misunderstood the point the GP was making. If the computer internally stores the time as UTC then the stored time will always progress forward (UTC isn't affected by DST like GMT is), and behind the scenes it'll always be searchable. It's also about as future-proof as we can make it; if rules regarding leap years or calendaring in general change, you're screwed regardless of which system you're using. The DST translation should be done for display purposes only, based on the user's preferences for localization etc. Proper separation of content versus display logic should solve all of the problems you brought up. Those problems only become issues for people working with heterogeneous data sets (time stored differently in different data stores), in which case you'd expect to be writing translation routines anyways.

• #### Re:Complicated? (Score:4, Informative)

on Wednesday February 29, 2012 @09:02PM (#39204265) Journal

bool leap = !(year & 3 || !(year % 100) && year/100 & 3));

You do realize that at least on the x86 architecture that "year / 100 & 3" is two instructions, while "year % 400" will execute in the same time as "year / 100"...

• #### Re:Duh. (Score:5, Informative)

on Wednesday February 29, 2012 @10:22PM (#39204685)

Here is one the UTC/DST problems in a nutshell, and why it's not as simple as you think:
Assumptions:
-Me and my user are in UTC +10
-DST puts us into UTC +11
-DST runs from 1 October until 1 April

I am writing a "family reminders" application for mobile phones. A user enters two reminders. BOTH reminders are activated for the user and his wife, reminding them to take some medication. One is for 10 March 2010 at 1130AM and the other is for 10 April 2010 at 1130AM.

How do I store these date? I am a SMART programmer, and I store them as 2012-03-10_0030 and 2012-04-10_0130.
I was clever. I looked at the user's timezone setting, projected into the dates they were setting to appropriately modify the UTC time depending on DST or not.

Two things happen:
1. The user's wife flies to the west coast on 9 march, 3 hours earlier. On 10 march, do we alarm her at 8:30, per UTC? Or do we look at her new current time zone vs when it really was set and alarm her at 11:30 local time?

2. The "making summer longer" act is passed, extending DST to 15 April. Do we alarm them at 11:30am, or at 12:30pm? Why?

The solution to both of these is to give the users a bunch of checkboxes they don't quite understand, or to make assumptions that might wind up incorrect. Either way there's no "win win".

• #### Re:Duh. (Score:5, Informative)

on Thursday March 01, 2012 @06:45AM (#39206637)

You mean universal? That just means a standard.

A UTC formatted time stamp always contains a time zone

No, it doesn't. It never contains one -- it always represents local solar time in Greenwich, London (without getting into detail only of interest to astronomers).

However, it's often stored with a timezone, or processed using one. For example, RFC 2822 date format, which is what you get with
\$ date -R
Thu, 01 Mar 2012 10:29:22 +0000

I happen to be in London, so my timezone is +0000 right now.
\$ TZ=:Asia/Tokyo date -R
Thu, 01 Mar 2012 19:31:12 +0900

\$ TZ=:Europe/London date -R -d 'now + 80 days'
Sun, 20 May 2012 11:32:35 +0100
(+0100, for British Summer Time)

In these cases, what's being used is UTC and a location. The location (mine is set to Europe/London) is used to find the timezone offset for any particular date and time. This even takes into account historic (or known-future) changes:
\$ date -R -d '1941/07/01 12:00 +0000'
Tue, 01 Jul 1941 14:00:00 +0200
(Britain used "Double Summer Time" during World War 2)
\$ TZ=:Europe/Jersey date -R -d '1841/07/01 12:00'
Thu, 01 Jul 1841 12:00:00 -0001
(The island of Jersey, between England and France, didn't start using GMT until 1898)

#### Related LinksTop of the: day, week, month.

Thufir's a Harkonnen now.

Working...