The original French Republican Calendar determined the start of the year with the date of the autumnal equinox at the Paris Observatory. This made the calendar somewhat unpredictable, as it required a lot of astronomy to figure out the start of the year (and thus whether the previous year was a leap year). These days, it's common to see versions floating around with the same leap year rules as the Gregorian calendar instead of the original rules, leading to weird cases like having the wrong leap years compared to what happened historically.
I got nerd-sniped into making a calendar following the original rules and tried to see how far I can push it with modern astronomy, and this is the result.
Moon orbit (from there comes the original week and month) doesn't have to be proportional to Earths rotation (day), nor any of them with Earth's orbit around the sun (year and seasons). Those divisions had some original real life meanings (it was easier to track time by moon phases, and it was important to have a clue on where a season will start for agriculture) but being more accurate meant that some of those old meanings became more decorative or convention than something necessary. And things are a bit more complicated for agriculture than just the start of the seasons anyway (plants may be flowering earlier due to climate change)
Things would had been easier if our world behaved like i.e. Stardew Valley year (4 months=seasons, 28 days/4 weeks each month, no leap years, and the start of each season mean an abrupt change of conditions)
It does that annoying thing where it immediately adds a history state as soon as the page loads, so that the back button doesn't do anything. Would be nice to see this fixed. Otherwise well done.
Thanks for reporting! I didn't notice since I always navigated directly to the page while testing, but it is rather annoying when linked. I just pushed a fix.
I own a beautiful version that also has a drawing of the specific theme of the day. Unfortunately sold out, and probably will not be in print anymore because was too much work the artist. Although I now do see on her twitter she is willing to off load the work to someone else, so if someone is interested..
If the time portion of the view isn't using `requestAnimationFrame`, it probably should be. Otherwise deferring to `setInterval` sets a weird cadence for the time changing.
It's actually using setTimeout. Every time the callback fires, it calculates exactly how many milliseconds it would take before the next second arrives, and schedules another timeout exactly that many milliseconds later. This is done separately for both decimal and 24-hour time to ensure the most accurate time is shown.
I believe this avoids the weird issues with setInterval but does not use as much CPU as requestAnimationFrame.
I made a decimal time clock here https://github.com/wegry/decimal-time where I used `requestAnimationFrame`. Admittedly, it probably uses more CPU than it should.
> In this Fiddle, you can clearly see that the timeout will fall behind, while the interval is almost all the time at almost 1 call/second (which the script is trying to do). If you change the speed variable at the top to something small like 20 (meaning it will try to run 50 times per second), the interval will never quite reach an average of 50 iterations per second.
I got nerd-sniped into making a calendar following the original rules and tried to see how far I can push it with modern astronomy, and this is the result.