Freshman year of uni I memorized some variant of this, and after some practice I got to where I could do the math in 3-5 seconds.
Protip: Some parts of the algorithm can be subject to a CPU/Memory trade off. In the variant presented in the wiki article, steps 1 and 2 can be combined. Memorize the doomsdays for all of the years of people you're likely to want to calculate their date of birth. For me, this meant memorizing the doomsdays between say, 1980 and 1995.
You can also memorize a modulo 7 table for all numbers you're likely to encounter.
You can get fast enough in the amount of time it takes you to say some canned response "Hmm, I think the date X YYth of ZZZZ would fall on..." you can figure out the answer.
-----
Though it turns out this is a significantly less impressive party trick as I initially imagined it'd be.
Only a certain kind of people really appreciate it.
Generally, the same kind of people who are impressed by rubik's cube speedsolving (which I also thought would be amazingly cool) are impressed by this. But for a lot of people, they just assume there is some simple trick to it, say "cool" and move on.
And then other people assume you must be some sort of autistic savant.
Fortunately, I've found that most people know which day of the week they were born on. Once or twice, though, someone was mistaken and upon consulting wolfram alpha, we determined the doomsday algorithm was correct.
(CC=century digits F=First S=Second digit of the last two digits in year)
Note:Only for Gregorian calendar.
Formula=
{D
+Table(M) -1 IF month=1or2&leap_year
+Table(CCmod4)
+Table(F)
+Table(S +2 IF F is odd)
} mod7
Tables are:
Month {033614625035} or Jan=0 Feb=3 Mar=3 Apr=6 etc.
Century {6420} or 16xx=6 17xx=4 18xx=2 19xx=0 20xx=6 etc.
TableFirst memorize {0340145025} or {00,13,24,30,41,54,65,71,82,95}
TableSecond memorize {012356013456} or {00,11,22,33,45,56,60,71,83,94,105,116}
FormulaResultTable:1=Monday...6=Saturday 0=Sunday
Example: 16 August 2014 = (16+2+6+3+0)mod7=6=Saturday
In this method,I find slight advantage over "odd+11 method" because
my method does not involve two digit arithmetric (and memorizing running total if you're not calculating FS first),although learning tables take some time.
When I wrote my time and date library (luatz: https://github.com/daurnimator/luatz ) I originally wrote an implementation of the Doomsday rule to figure out the day of the week.
IIRC tzdata just acquired a new version (3) not too long ago and luatz would need to be updated to handle it. You'll only get the new files if they were compiled with a newish zic. This bit me because code I work with is also parsing them :)
It seems the algorithm would be better optimized for humans if January and February were always considered to be the last two months of the previous year. We're already used to doing this when working out birth years for Horoscopes and the Chinese calendar. Then we wouldn't need to memorize different dates for Doomsday in Jan and Feb, and instead remember Jan 2, Feb 6, etc.
I do believe the etymology in this case lies with Old English 'domes dæg' which was thought to be some apocalypse 6,000 years after creation, which was thought to be ca. 5,200BCE.
As for your question why, I cannot reasonably guess. :-)
Somewhat related, you may be interested to read up about the Doomsday Book.
Not sure how the doomsday works, but there's a quick way to calculate the day of week just memorizing single digit codes for months. Might be easier to grok from a small script. This is for current century (2000s) in coffeescript:
calculateDay = (year,month,day) ->
y = (year-2000)%28
m = [6,2,2,5,0,3,5,1,4,6,2,4][month]
if month < 2 and y%4==0
m-= 1
y += y/4|0
days = ['Sun','Mon','Tue','Wed','Thu','Fri','Sat']
return days[(y+m+day)%7]
---
For years 1600s through current century here's a jsfiddle with a slightly longer method with verification: http://jsfiddle.net/9zp0zkxz/
Edit: no idea how to work spacing on comments here
Thanks, Jeff! The key to the Periodic Calendar is identifying that there are seven types of years, depending on the day of the week that starts it off. At first I thought I needed to make 7 calendars to cover the possibilities, but my aha moment came with the idea of the Gregorian Isotopes, which flip our focus from the day of the month to elements based in days of the week that exist on an array of days of the month.
The core idea is that August 10th is a semi-meaningless count of the days, whereas the real information lies in today being Sunday.
As I explained to a friend recently, I'm not the type of person who can readily do the calc in my head, but rather the type who would enjoy the tedious work of laying out all the possibilities on paper, as I did with the Periodic Calendar: http://periodiccalendar.com/
Protip: Some parts of the algorithm can be subject to a CPU/Memory trade off. In the variant presented in the wiki article, steps 1 and 2 can be combined. Memorize the doomsdays for all of the years of people you're likely to want to calculate their date of birth. For me, this meant memorizing the doomsdays between say, 1980 and 1995.
You can also memorize a modulo 7 table for all numbers you're likely to encounter.
You can get fast enough in the amount of time it takes you to say some canned response "Hmm, I think the date X YYth of ZZZZ would fall on..." you can figure out the answer.
-----
Though it turns out this is a significantly less impressive party trick as I initially imagined it'd be.
reply