Re: Calendar programming

I noticed that I threw out a bunch of math without much explication. Let
me offer a small beginning of a correction to that oversight.

Calendar units necessarily consist of whole numbers of days - having,
say, New Year's Day start at midnight but the 1st of February start at
noon would take calendrical inconvenience to a whole new level.  If the
number of days per unit is always the same - as in the week, which is
always seven days - then the math is easy.  Divide the global day count
by the size of the unit; the quotient tells you how many units there
have been, while the remainder tells you how far into the current unit
you are.

For instance, given a date in the Rata Die count you can quickly find
out what day of the week it is, with only one other fact at your
disposal: that RD 1 was a Monday.  The number 1 divided by 7 leaves a
remainder of 1, obviously, so the remainder when divided by 7 maps to
days of the week as follows: 0 (i.e. the RD is an even multiple of
7)=Sunday, 1=Monday, 2=Tuesday, 3=Wednesday, 4=Thursday, 5=Friday,
6=Saturday.

Today is RD 731,697.  731,697 divided by 7 yields 104,528 with a
remainder of 1.  I don't much care that there have been 104,528 complete
weeks since January 1st, AD, but the remainder tells me that today must
be a Monday.  Unfortunately. :)

My birthday, as I calculated in the last message, was RD 718,557.
718,557 divided by 7 yeilds 102,651 exactly - no remainder.  So I
was born on a Sunday.   Cue jokes about the Childe that is born on the
Sabbath Day.

This same technique would work for months and years if months and years
were always the same number of days; sadly, that is not the case.  The
times between astronomical events which these units approximate are not
whole numbers of days, so if the units were a constant whole number
of days the calendar would quickly get out of synch with astronomical
reality.  For example, a lunar month is about 29.5 days; a tropical year
is about 365.25 days; a "solar month" of the type we have in our
calendar (really just 1/12 of the tropical year) is about 30.4375 days.
Rather than have units extending into fractions of a day (see earlier
remark about new levels of inconvenience), real calendars have units
whose size changes.  The idea is pretty simple: one lunar month is 29.5
days, which is not a whole number, but that makes two lunar months equal
to 59 days, which is a whole number.  So if the calendar month lengths
alternate between 29 and 30 days, the *average* calendar month will be
29.5 days, and the calendar will never be more than a day off of the
desired schedule.  Similarly, one tropical year of 365.25 days is not a
whole number, but four tropical years add up to 4 x 365.25 = 1,461 days.
So pick one of the four years and stick the extra day on it, turning
4 x 365.25 into 3 x 365 + 366, and the calendar stays generally on
track, again never deviating by more than a day from the goal.

To handle these complications when converting from a fixed day count like the
RD, you group units together into something called a "cycle".  Instead
of dividing by the number of days in one unit, you divide by the number
of days in a cycle of units.  Identifying the appropriate cycle size can
be tricky - you have to find the smallest number of units which create a
cycle that repeats indefinitely in exactly the same pattern.  In our
hypothetical examples above, that'd be two lunar months or four tropical
years.

But things are not that simple in real calendars, because the lunar
month isn't exactly 29.5 days; it's more like 29.53059... - and even
that's just an average, as months are longer near the beginning of the
year and shorter near the middle.  Similarly, the tropical year isn't
exactly 365.25 days; what it is "exactly" depends on what point in the
year you measure from, but our calendar is based on the time between
March equinoxes, which averages about 365.2424... days.  So more
complications are added to the calendars to keep things in synch.  In
the case of the calendar with lunar months, then on some periodic basis
some month which would normally have 29 days is given 30 days instead.
In the case of the calendar with solar years, you might decide to skip a
leap year every 100 years . . .  but that makes the average year 365.25
- 1/100 = 365.25 - 0.01 = 365.24 days, which is now too small.  So every
400 years you put a leap year back, taking the average up back up to
365.24 + (1/400) = 365.2425 days.  That's the way the Gregorian calendar
works, and the resulting average calendar year is close enough to
the tropical year that we don't have to worry about it getting out of
synch with the seasons for a long, long time.

But these complications in the calendar further complicate the conversion
arithmetic.  In the case of the Gregorian calendar, four years is no
longer the cycle we need for our calculations, because three times in
every 400 years you get a four-year cycle that has a different number of
days (1,460 instead of 1,461, due to the skipped leap year).  So we have
to move up to a 100-year cycle of 36,524 days.  Except that's *still*
not our desired endless-repeater, because every fourth set of 100 years
is actually 36,525 days instead.  So the smallest indefinitely-repeating
cycle in the Gregorian calendar is 400 years, which add up to 146,097
days.  Once you know where a date is in the latest such cycle, you'll know
whether it's in a 36,524-day or 36,525-day cycle of 100 years, and
whether it's in a 1,460-day or 1,461-day cycle of 4 years, and finally
whether it's in a 365-day or 366-day leap year; that is the math I
worked through in my last message.

-Mark