Background:
Introduction
Part 1: Simulating candle-light with pseudo-random sequences
Part 2: Some physical structure
I want the Maccabeam to automatically determine when to illuminate the lasers (“candles”). Specifically, they should light at the beginning of each night of Hanukkah, and burn for about an hour. So how will it know when the time comes?
One of the hardware components f the Maccabeam is a GPS receiver. The specific model I got is this now discontinued model, but there are many equivalents. They’re miraculous little circuits: they have an antenna with which they receive signals from a constellation of sophisticated satellites, and they spit out a stream of information. This specific model has a 9600 baud serial output that provides timestamp and coordinate information, along with a highly-precise pulse-per-second (PPS) signal. To oversimplify, my software running on the Teensy gets very accurate time, date, and location information.
So, I know what time and date it is. Problem solved, right? Not exactly. Hanukkah is a holiday that falls on the same day every year — on the Hebrew calendar that is: the 25th of Kislev. The GPS yields data on what’s the usual, every-day calendar in the US, also known as the Gregorian calendar. I can find December in the Gregorian calendar, but not Kislev! Still, given that both calendars are used to measure time, it should be pretty easy to convert between them, right? Once again, not exactly.
The Gregorian Calendar is a Solar calendar, meaning that the year is tied to the position of the earth relative to the sun; one revolution around the sun is one year. The solar year is divided into months by set numbers of days, so a given month will find Earth in the same orbital position every year. The Hebrew calendar, however, is a Lunar-Solar calendar. That means the year is based on the months, and months are tied to the phase of the moon. What makes a Lunar-Solar calendar complicated is that the Solar year is not evenly divisible by the moon phases. A lunation or lunar phase (meaning from full moon to full moon, or new moon to new moon) is roughly 29.5 days, while the solar year is close to 365.24 days. That gives us 12.38 lunar cycles per year. You can see how the Gregorian calendar adding an extra day every four years (with a few exceptions) keeps the year in sync with the seasons. The Hebrew calendar uses a similar approach, except it’s a leap month! This month gets added on a complicated schedule, which works out to roughly seven times every nineteen years. This ensures a given month will fall in a given season. Interestingly, not all calendars are concerned with having months correlated with specific seasons. For example, the Islamic calendar is purely lunar, which is why Islamic holidays are not tied to seasons and they drift relative to the Gregorian calendar.
In any case, for the Maccabeam to work, I need an algorithm to convert from the Gregorian calendar to the Hebrew calendar. The usual approach is to find a specific moment in time, figure out the date in both calendar systems, figure out how many days have passed since that specified moment, and then calculate months and days from that number. I relied upon the authoritative technical book on the subject, Calendrical Calculations by Nachum Dershowitz and Edward Reingold. They discuss this conversion problem in enormous detail, and provide LISP code [!] to convert between many different kinds of calendars (Gregorian, Julian, Coptic and Ethiopic, Islamic, Hebrew, Ecclesiastical, Old Hindu, Mayan, Balinese Pawukon, Persian, Baha’i, French Revolutionary, Chinese, modern Hindu, and Tibetan). They also provide some thought-provoking discussion of units of timekeeping (what does a “day” mean for a someone living above the Arctic Circle, for example, or why would someone who lived on the Equator care about solstices, or even what’s the purpose of units like the week?)
To make a long story short, I used their algorithms to implement a C version of the conversions between Hebrew and Gregorian calendars. So now I’m set, right? Well, still not quite. There are still a few problems.
First, we have to go back to the realization that measuring time is complicated, and even simple concepts like “days” are not simple. In the Gregorian calendar, the start of the day is at a point in time we call midnight, 12:00 AM. Historically, this was set a the halfway point between sunset and sunrise (or twelve hours from the Sun’s highest position in the sky), but now it’s more abstract. We have time zones loosely based on a geographic offset from Greenwich England. Seems … uh … simple. The Hebrew calendar, however, doesn’t use midnight as the point when the date changes — instead, the day begins at sundown. So even if I know the exact date on the Gregorian calendar, it’s one of two days in the Hebrew calendar depending on whether the sun has set or not.
Oh, and one other problem. The GPS gives me time and date, but not the time and date for my specific location. No, it’s giving me time in Coordinated Universal Time (UTC), which is the time at 0º longitude1. To go from UTC to local time, you need to know your time zone. For example, if it’s midnight at UTC, it’s still the previous date in Los Angeles, but you can’t know that unless you have a map that tells you how many hours Los Angeles is offset from UTC. Similarly, if you’re east of the 0º longitude, for certain hours you will be a day ahead of UTC.
Time zones are quite a thing. If you want to know whether a programmer has ever had to deal with them, just say something like “my code works prefectly except in Nepal” and see if they start shedding tears and muttering about UTC + 5.75. Meanwhile, I’m in Los Angeles. Time for me is either 7 or 8 hours behind2 UTC depending on whether it’s Daylight Saving Time or Standard Time. Oh yes, another complication! When you mix Daylight Savings Time into the equation, you discover you need to know your political boundary down to the county level to know whether to shift an hour or not!
There are code libraries where you enter your latitude and longitude, and they will tell you the time zone and whether or not DST is in effect. These libraries get updated frequently, and they are not small. They will not fit in the memory of my Teensy. But all is not lost! Remember that the Hebrew day starts at sundown? So we don’t have to know the local clock time, we need to know the local sunset time. Given your coordinates and the time at UTC, you can compute sunrise and sunset times. Before we get too confident and start thinking this is perfectly straightforward, let’s note that there are multiple definitions of sunset. Technically, it’s defined as when the upper edge of the sun disk is behind the curve of the earth, but atmospheric refraction makes the sun visible even when it’s past that mark. When you see the sun set, it can actually be several degrees beyond that point. That’s why there are different definitions of civic, nautical, and astronomical twilight. Still, for simplicity’s sake, we’ll use geometric sunset.
Given the date and time at UTC and the sunrise/sunset time locally, you can figure out if it’s the same Hebrew day without needing to know anything about time zones or daylight savings time. With code that gives the sunrise and sunset times in UTC for your location, you can calculate sunrise and sunset times for for the current date, the previous date, and the next date. Then you can figure out which of those events have passed, and which are yet to occur. If it’s before sunset of the previous UTC date, you subtract one. If it’s after the sunset of the current UTC date, you add one.
In any case, I used Paul Schylter’s sunriseset.c library to compute the geometric sunset, and then figure out if I need to add or subtract from the date after converting. So now I can compute the correct Hebrew date, and I can also compute the number of hours and minutes to sundown. So if it’s the 24th of Kislev, I can count down the hours and minutes until the date clicks over to the 25th, and Hanukkah begins. Hooray! We now know when it’s Hannukah!
1 Strictly speaking, UTC is not exactly the time at 0º, but is kept within a second or so of it. For my purposes, I consider it the same.
2 This is often confusing, because UTC is 7 or 8 hours ahead of Los Angeles time, but the notation is UTC-7 or UTC-8, which might make you think Los Angeles is ahead. But it’s clearer when you look at the math, e.g., when it’s say 18:00 UTC, it’s 10:00 PST.