Optimizing with Novel Calendrical Algorithms
9 comments
·February 3, 2025picafrost
This is a great and very interesting write-up. It has never occurred to me that there might be algorithms applicable to calendars.
It strikes me that the Gregorian calendar might encode some of the most calcified tech debt of humanity. It attempts to fit solar, lunar, and 7-day religious-oriented cycles (and who knows what else?) into one system. So many cultural and religious touchstones are oriented around the (month, day) tuple. For extra confusion add the asymmetry between cultures who place traditions on the lunar calendar. Let's not mention timezones. A big thanks to you keepers of time (libraries).
Deciding that time began with Unix and that it should simply count forward seems rather sane by comparison.
ratmice
My favorite technical debt is the off-by-two naming of quintilis through december from when they added Jan and Feb to the beginning of the calendar...
TeMPOraL
Yup. And directly related to that, the absurdity of having the second month be the one that has weird numbers of days and gets a regular extra day to keep the calendar in sync with Earth's revolutions. Adding or removing a day from the end of the year is the obvious choice, so why not do it there?
Turns out, people who came up with the leap year weren't stupid - the extra day used to be tacked to the end of a year. But then the thing you mentioned happen, the calendar was rotated right (in the positional arithmetic sense) by two, and what used to be the last month of the year is now called February.
ratmice
Yeah, I never understood why they couldn't make it Dec-Feb-Jan with January at the end of the year so that Janus could still be the god of transitions, but I guess I'm no theologian so there is probably a reason.
jkafjanvnfaf
Nice writeup and algorithm. My first instinct would have been to take the lazy way out and just use a table with 365 entries (or 366, or both depending on the implementation), but this is a lot more elegant.
weinzierl
Why does the number of Total Cycles increase for the faster version?
mmastrac
There is a preliminary version with more -- but the final version has fewer cycles
zokier
It is still bit odd considering tha in the actual benchmarks the preliminary version is significantly faster than the old one. So there seems to be fairly large discrepancy between the cycles estimation and actual runtime
The article leaves out optimizing is_leap_year. Here is an interesting version that is correct (in the Proleptic Gregorian calendar) for 0 <= year <= 102499 and takes only 3 instructions:
How this works is surprisingly complex, I am thinking of writing a whole blog post about it...