 |
Calendar Curiosities Mike Keith |
Calculating the day of the week
The ordinary (Gregorian) calendar is a somewhat messy affair. Different months have different numbers of days, and there is the problem of leap years. Do you even remember the rule for leap years? (Answer: a year is a leap year if it is divisible by 4, unless it's divisible by 100 in which case it isn't, unless it's divisible by 400 in which case it is).
I once set myself the following problem: Given an arbitrary month (m= 1 to 12), day (d= 1 to 31), and year, find the simplest possible formula (entirely self-contained, with no recourse to tables of "magic numbers") that correctly calculates the day of the week D (0 = Sunday, 1 = Monday, ... 6 = Saturday). What does "simplest possible formula" mean? Well, here's a way to quantify it: make it an expression in the C programming language that's a few characters long as possible.
Given the complications involved, it's quite surprising how short an expression will do. I believe that the following formula, a mere 45 characters, is the best that can be done:
(d+=m<3?y--:y-2,23*m/9+d+4+y/4-y/100+y/400)%7
Try it, it works! Note that the expression may modify the value of y, so it's best to use it in a subroutine. Also note that some of the convolutedness of the expression is due to the need to ensure that it unambiguously follows the C language rules for order of expression evaluation (in other words, to make sure that its value is compiler-independent).
Why does it work? Here is a brief explanation, condensed from my paper in Journal of Recrational Mathematics, Vol. 22, No. 4, 1990, p. 280:
First, let's write the formula in a longer but simpler form:
dayofweek = ( [23m/9] + d + 4 + y + [z/4] - [z/100] + [z/400] - 2 (if m >= 3) ) mod 7
where
[x] means to truncate downward to the nearest integer, and
z = y - 1 if m < 3,
z = y otherwise.It's relatively easy to see that this is equivalent to the C version. We now prove that the formula is correct by induction; that is, we first assume it is correct for some date, and then show that it correctly adjusts the sum modulo 7 based on the number of years, months, and days that have elapsed since the "base date".
Assume for the moment that February has 30 days (we'll correct for this later). Then the number of days in each of month is 31, 30, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31, which modulo 7 is 3, 2, 3, 2, 3, 2, 3, 3, 2, 3, 2, 3. Now stick a 2 before this sequence and a 2 3 2 3 3 after it, and you get (2) 3 2 3 2 3 2 3 3 2 3 2 3 (2 3 2 3 3), which is just 2,3,2,3,2,3,2,3,3 repeated twice. But - this is the key - these numbers are the first differences of the sequence [23m/9] = (2,5,7,10,12,15,17,20,23). Therefore, the term [23m/9] adds the sum (mod 7) of the total number of days in months 1 to m-1 to dayofweek, thus correctly adjusting the formula for the months that have passed prior to m.
The next term, d, simply adjusts the sum based on the day of the month. The constant term, 4, shifts the result to correctly align with the calendar. The next term, y, adds 1 for each passing year, since 365 = 1 mod 7. The next three terms add 1 (the leap day) for each leap year that's passed since the "base date", including this year. To complete the correct formula requires handling two exceptions:
(1) If m >= 3 (we are later than February), then we must subtract 2 because February actually has 28 days rather than the 30 we assumed.
(2) If m < 3 (the opposite case), then we must use z = y-1 rather than z = y. This causes the leap-day correction term to not include the leap day for the given year, since in this case it hasn't yet occured.
This formula is similar in spirit to Zeller's Congruence, but can be expressed in C more concisely than Zeller's formula.
You can use this formula to easily verify that the 13th of
a month is most likely to occur on a Friday (the probability
is exactly 43/300, as opposed to 42.9375/300 for the two
runner-ups).
Numerically interesting dates and times
When we write the time and date, it's usually in a form something like
hh/mm/ss on mm/dd/yy
On July 8, 1990 - the reason for this date will become clear - I realized that there are some especially interesting moments in time, in which the digits in this expression are either
- in ascending (possibly with wraparound from 9 to 0) order
- in descending (possibly with wraparound) order, or
- identical
A simple, but fun problem: how many such instants are there in each century? The answer is 20, and they are shown in the table below (sorted in chronological order):
Time and Date Date Type 1:11:11 1/1/11 Jan 1, '11 same 11:11:11 1/1/11 Jan 1, '11 same 1:11:11 1/11/11 Jan 11,'11 same 11:11:11 1/11/11 Jan 11,'11 same 1:11:11 11/1/11 Nov 1, '11 same 11:11:11 11/1/11 Nov 1, '11 same 1:11:11 11/11/11 Nov 11,'11 same 11:11:11 11/11/11 Nov 11,'11 same 2:22:22 2/2/22 Feb 2, '22 same 2:22:22 2/22/22 Feb 22,'22 same 3:33:33 3/3/33 Mar 3, '33 same 4:44:44 4/4/44 Apr 4, '44 same 5:55:55 5/5/55 May 5, '55 same 3:21:09 8/7/65 Aug 7, '65 desc 9:01:23 4/5/67 Apr 5, '67 asc 4:32:10 9/8/76 Sep 8, '76 desc 6:54:32 10/9/87 Oct 9, '87 desc 1:23:45 6/7/89 Jun 7, '89 asc 12:34:56 7/8/90 Jul 8, '90 asc 2:34:56 7/8/90 Jul 8, '90 asc
As you can see, if you missed the ascending event on July 8, 1990, the next one that's either ascending or descending is not until 75 years after that (in 2065)! Well, at least there will be some repeated-digit ones in the year 2011. A final factoid: there are no additions to the above list even if we allow European-style dates (dd/mm/yy rather than mm/dd/yy) or 24-hour (military) time. Go ahead, figure out the proof, it'll do you good!
Another interesting moment occurs every year at 34 seconds before two o'clock on March 14. (I always like to state it this way as it makes it a more interesting puzzle.) Do you see it? If we write the date and time in order, we get:
3/14, 1:59:26
which gives the first eight digits of the number π. We can also use time+date instead of date+time, which yields:
3:14:15 on 9/26
which is particularly interesting once every 100 years (in
the years ending in "53").
New York Minutes
Suppose an hour, minute, day, month, and year are written down on five pieces of paper and mixed. Define a New York Minute as an instant in time for which it is possible to reconstruct, by logical argument, the original order of the five fields. (This nomenclature is a reference to the song "New York Minute" by Don Henley, in which "everything can change". In a New York Minute, everything can change and yet it is still possible to reconstruct the original order.)
Do New York Minutes exist? The answer is "yes": for example, 9:47 on 12/31/90. The 90 must be the year, as it is too large for any other field, and similarly 47 must be the minute and 31 must be the day. The remaining two (9 and 12) are uniquely determined because September has only 30 days, so 9/31 would be illegal. Now for the puzzle: How many minutes elapse between the last New York Minute in 1999 and the first New York Minute in 2000?
Since the calendar repeats exactly every 400 years (proof: there are 97 leap days every 400 years, and 365*400+97 is a multiple of 7), it is possible to calculate exactly how many New York Minutes there are. This number is 3,782,800 out of the 210,379,680 minutes in 400 years. In other words, about 1.8% of all minutes. But note that these are very irregularly spaced relative to the years. The years 1998 and 1999 each have 23,256 New York Minutes, but the year 2000 only has 622! (In fact, not until the year 2060 are New York Minutes as plentiful as they are in 1999.)