On Nov 18, 9:02 am, Yves <sunder_1...@yahoo.com> wrote:
> Q: Which two days, Saturday or Sunday, does New Year's Day fall more often?
In a Julian Calendar, they fall an equal number of times over any period of 28 years (namely, 4 times, same as every other day); it gets a little trickier in the Gregorian calendar if the period includes a non-leap year that is a multiple of 28.
Yves wrote: > Q: Which two days, Saturday or Sunday, does New Year's Day fall more often?
> Which rule is recommended? I read about the Doomsday Rule, Zeller etc.
Appreciate advice.
Over what time period? Or do you mean on average from now onwards?
For these types of calculations I generally convert the calendar date to Julian day number, then determine the weekday number from that. I do this mainly because I do a lot of tinkering with astronomy related algorithms which tend to use a Julian day numbers.
On Wed, 18 Nov 2009 15:00:45 -0500, Greg Neill wrote: > Yves wrote: >> Q: Which two days, Saturday or Sunday, does New Year's Day fall more > often?
>> Which rule is recommended? I read about the Doomsday Rule, Zeller etc. > Appreciate advice. > Over what time period? Or do you mean on average from now onwards? > For these types of calculations I generally convert the calendar date to > Julian day number, then determine the weekday number from that. I do > this mainly because I do a lot of tinkering with astronomy related > algorithms which tend to use a Julian day numbers. > JD(day,month,year) = 367*year > - INT(7*(year + INT((month + 9)/12))/4) > + INT(275*month/9) + day + 1721013.5 > WD(JD) = (floor(JD) + 2) MOD 7 > where: Sunday = 0, Monday = 1, Tuesday = 2, ... > So, for example, January 1, 2010 gives: > JD(01,01,2010) = 2455197.5 > WD(2455197.5) = 5 (Friday) > If I run a loop from January 1, 1900 through January 1, 5800 and count > the number of times each day comes up I get: > Sun 571 > Mon 572 > Tue 572 > Wed 572 > Thu 572 > Fri 571 > Sat 571 > So for that particular time period Saturday and Sunday New Year's > Day occur an equal number of times.
Your totals add up to 4001 years instead of the expected 3901. Did you mean to continue through January 1, 5900 instead of 5800?
There is no point in going beyond 400 years, since the Gregorian calendar repeats with a period of 400 years. For the period 1/1/1900 through 1/1/5900, I get:
Sun 580 Mon 561 Tue 580 Wed 570 Thu 570 Fri 580 Sat 560 --- TOTAL 4001
which is obtained by multiplying the 400-year totals by 10 and adding one extra Monday for the 4001st year, since January 1, 5900, is a Monday.
> There is no point in going beyond 400 years, since the Gregorian calendar > repeats with a period of 400 years. For the period 1/1/1900 through > 1/1/5900, I get:
> Sun 580 > Mon 561 > Tue 580 > Wed 570 > Thu 570 > Fri 580 > Sat 560 > --- > TOTAL 4001
> which is obtained by multiplying the 400-year totals by 10 and adding one > extra Monday for the 4001st year, since January 1, 5900, is a Monday.
On Wed, 18 Nov 2009 15:00:45 -0500, Greg Neill wrote: > Yves wrote: >> Q: Which two days, Saturday or Sunday, does New Year's Day fall more > often?
>> Which rule is recommended? I read about the Doomsday Rule, Zeller etc. > Appreciate advice. > Over what time period? Or do you mean on average from now onwards? > For these types of calculations I generally convert the calendar date to > Julian day number, then determine the weekday number from that. I do > this mainly because I do a lot of tinkering with astronomy related > algorithms which tend to use a Julian day numbers. > JD(day,month,year) = 367*year > - INT(7*(year + INT((month + 9)/12))/4) > + INT(275*month/9) + day + 1721013.5 > WD(JD) = (floor(JD) + 2) MOD 7 > where: Sunday = 0, Monday = 1, Tuesday = 2, ... > So, for example, January 1, 2010 gives: > JD(01,01,2010) = 2455197.5 > WD(2455197.5) = 5 (Friday) > If I run a loop from January 1, 1900 through January 1, 5800 and count > the number of times each day comes up I get: > Sun 571 > Mon 572 > Tue 572 > Wed 572 > Thu 572 > Fri 571 > Sat 571 > So for that particular time period Saturday and Sunday New Year's > Day occur an equal number of times.
I implemented your algorithm in C as shown at the end of this post. Using this definition, I was able to reproduce your counts for the period 1800 <= year <= 5800. However, your algorithm seems to be wrong for pretty much all dates beginning in the year 2101. For example, your algorithm says January 1, 2101, is a Sunday. Actually, it's a Saturday.
[orion:~] $ cal 1 2101 January 2101 Su Mo Tu We Th Fr Sa 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Here is how I implemented your JD algorithm:
int JDweekday(int day, int month, int year) { double JD = 367*year - (int) (7*(year + (int) ((month + 9)/12)) / 4) + (int) (275*month/9) + day + 1721013.5; return ((int) (JD) + 2) % 7;
}
For comparison, here is Zeller's congruence, which is one of two ways that I computed my results (I also used a different method to check):
int zeller_dow(int day, int month, int year) { if (month < 3) { month += 12; year--; } return ((13*month+3)/5 + day + year + year/4 - year/100 + year/400 + 1) % 7;
}
In each case, we are supposed to have 0=Sun and 6=Sat. Yours is correct for the 21st century, but the error seems to increase by one day for each century year that is a non-leap year in the Gregorian calendar (2100, 2200, ...).
> I implemented your algorithm in C as shown at the end of this post. > Using this definition, I was able to reproduce your counts for the > period 1800 <= year <= 5800. However, your algorithm seems to be > wrong for pretty much all dates beginning in the year 2101. For > example, your algorithm says January 1, 2101, is a Sunday. Actually, > it's a Saturday.
Yep. There seems to be a bug in theJulian Day calculation I used that crops up at the year 2101. Thanks for pointing this out; I'll need to take another look at it.
I was attempting to come up with a compact single line function for Julian Day that didn't require auxilliary temporary variables. Back to the drawing board...
> > I implemented your algorithm in C as shown at the end of this post. > > Using this definition, I was able to reproduce your counts for the > > period 1800 <= year <= 5800. However, your algorithm seems to be > > wrong for pretty much all dates beginning in the year 2101. For > > example, your algorithm says January 1, 2101, is a Sunday. Actually, > > it's a Saturday.
> Yep. There seems to be a bug in theJulian Day calculation > I used that crops up at the year 2101. Thanks for pointing > this out; I'll need to take another look at it.
> I was attempting to come up with a compact single line > function for Julian Day that didn't require auxilliary > temporary variables. Back to the drawing board...
Classic issue would be to ignore the 100 and 400 year leap rules, thus getting an answer that's correct for March 1, 1900 through February 28, 2100. It's a tempting approximation/simplificatino.
Looking at your formula, I see the part that involves year has a factor of exactly 365.25 on it. [367 - 7/4] So the century rules are indeed missing and you probably have calendar creep of 3 days for every 400 years.
> On Nov 19, 10:38 am, "Greg Neill" <gneil...@MOVEsympatico.ca> wrote:
> > Dave Seaman wrote:
> > > I implemented your algorithm in C as shown at the end of this post. > > > Using this definition, I was able to reproduce your counts for the > > > period 1800 <= year <= 5800. However, your algorithm seems to be > > > wrong for pretty much all dates beginning in the year 2101. For > > > example, your algorithm says January 1, 2101, is a Sunday. Actually, > > > it's a Saturday.
> > Yep. There seems to be a bug in theJulian Day calculation > > I used that crops up at the year 2101. Thanks for pointing > > this out; I'll need to take another look at it.
> > I was attempting to come up with a compact single line > > function for Julian Day that didn't require auxilliary > > temporary variables. Back to the drawing board...
> Classic issue would be to ignore the 100 and 400 year leap rules, thus > getting an answer that's correct for March 1, 1900 through February > 28, 2100. It's a tempting approximation/simplificatino.
> Looking at your formula, I see the part that involves year has a > factor of exactly 365.25 on it. [367 - 7/4] So the century rules are > indeed missing and you probably have calendar creep of 3 days for > every 400 years.
But that is the point of doing the Julian day first, isn't it? In the Julian calendar, the year is exactly 365.25 days in it, with a leap year every four years, no century rules. As I understood it, the point was to figure out the day it would be in the Julian calendar, and then adjust the day to the Gregorian one by taking into account the Julian calendar. Figuring out the Julian day is easy because you only have to add one day per year, plus one day for every four years. Then you take your Julian answer and adjust to the Gregorian one by taking into account the century rules. The formula you mention was for the Julian day.
For example, once Dave Seaman said the Gregorian cycle is 400 years long (the Julian cycle is only 28 years long), here is how I mentally checked that it: 400 days for the years, plus 100 for the leap years is 500; this is 3 mod 7, so the Julian day has crept forward 3 days. Take away the three extra leap years to get 0 mod 7 for the Gregorian day, so we've cycled in days of the week and in sequence of leap-and- non-leap years.
On 18-Nov-2009, Yves <sunder_1...@yahoo.com> wrote in message <1122694326.89835.1258556556145.JavaMail.r...@gallium.mathforum.org>:
> Q: Which two days, Saturday or Sunday, does New Year's Day fall more > often?
Others have answered your question with respect to the Gregorian calendar, which is probably what you meant.
But I thought I'd just point out that eventually (after several thousand years? I forget how long) we'll have to insert (or subtract? I forget which) an extra leap day if we want to keep the calendar year aligned to the seasons, because the tropical year isn't exactly 365.2425 mean solar days, as the Gregorian calendar would have it. Over much longer time scales than that, New Year's Day will fall with equal probability on every day of the week.
And in the *really* long run, the Earth will spin down until it's tidally locked to the moon, making each "day" longer than a month (= 1/12 year). But IIRC that will take many many billions of years, by which time the Earth will have long ago been consumed by the sun having gone through its Red Giant phase, if it hasn't already been ejected from the solar system altogether by chaotic gravitational interactions with the other planets, or if the solar system hasn't been ripped apart by a close encounter with another star, or ...
> Which rule is recommended? I read about the Doomsday Rule, Zeller etc. > Appreciate advice.
On Thu, 19 Nov 2009 12:32:17 -0800 (PST), Arturo Magidin wrote: > On Nov 19, 11:17?am, jbriggs444 <jbriggs...@gmail.com> wrote: >> Looking at your formula, I see the part that involves year has a >> factor of exactly 365.25 on it. ?[367 - 7/4] ?So the century rules are >> indeed missing and you probably have calendar creep of 3 days for >> every 400 years. > But that is the point of doing the Julian day first, isn't it? In the > Julian calendar, the year is exactly 365.25 days in it, with a leap > year every four years, no century rules. As I understood it, the point > was to figure out the day it would be in the Julian calendar, and then > adjust the day to the Gregorian one by taking into account the Julian > calendar. Figuring out the Julian day is easy because you only have to > add one day per year, plus one day for every four years. Then you > take your Julian answer and adjust to the Gregorian one by taking into > account the century rules. The formula you mention was for the Julian > day.
No, that is a misconception. The Julian Day (JD) is how astronomers measure time. It has nothing to do with the Julian calendar. JD is a continuous count of days from a certain date in the year -4712, which is how astronomers write 4713 B.C.E. The JD can be computed either from the Julian calendar or the Gregorian calendar. Here is a description of the algorithm, adapted from Meeus: _Astronomical_Algorithms_ and rewritten in a C-like syntax:
Let Y = year, M = month (1=Jan, 12=Dec), and D = day of month (possibly including a decimal part).
if (M < 3) { M = M + 12; Y = Y - 1 }
// adjust for Gregorian calendar, if needed: switch (calendar_type) { case gregorian: A = Y/100; B = 2 - A + A/4; break; case julian: B = 0; break; }
JD = (1461 * (Y + 4716))/4 + (153 * (M+1))/5 + D + B - 1524.5;
The JD is arranged so that an astronomical day begins and ends at noon, which makes perfect sense for astronomers.
On Nov 19, 5:39 pm, Dave Seaman <dsea...@no.such.host> wrote:
> No, that is a misconception. The Julian Day (JD) is how astronomers > measure time. It has nothing to do with the Julian calendar. JD is a > continuous count of days from a certain date in the year -4712, which is > how astronomers write 4713 B.C.E.
|
