I was recently contacted by Jan Terje Johansen, a developer at Datek Wireless AS in Norway, with an interesting bug report. Datek uses the Zmanim API (the AstronomicalCalendar base class) to allow their clients (the power company and stadiums) to remotely (via a web interface) control streetlights and stadium lights throughout Norway using a wireless lighting control system that they developed. The zmanim code is used to allow setting the lighting times based on an offset of sunrise/sunset. For the technically curious, they are controlled primarily through GPRS, with SMS as fallback. A version under development uses ZigBee. The bug encountered was that for Tromsoe (Tromsø), Norway, as well as other areas within the Arctic Circle that experience the midnight sun, from May 13th to May 17th (the date of last rise of the season in Tromsoe), the zmanim API produced correct sunrise/set times, but the date component (The API returns all times as Java Dates, something that might change with v2.0 of the API that will target JDK 7 to take advantage of JSR-310 Date and Time API) was a day off. For non-automated systems, the date component is not important, but in their case it would cause the lights to go on/off on the wrong day. Jan provided a suggested patch that worked well. The actual fix I used was slightly different because I took advantage of the time spent on fixing the bug to refactor and simplify the code. This change as well as a few other changes are part of the Zmanim 1.1 beta release that will likely be released as a final release in a few days. Jan mentioned that:
“IMHO your API is easily the best and most accurate Open Source sunset/sunrise API out there”. He continued: “Officially (according to the Norwegian Meteorology Institute), the midnight sunset/sunrise is from May 20 to July 22 in Tromsoe, ie. the complete sun is above the horizon 24 hours. Parts of sun is visible 24 hours a day in Tromsoe from May 18th to July 25th. This is the same as in your calculations.” … “I have tested your calculations against other official midnight sunrise/sunset (part of sun) dates in Northern-Norway (North Cape, Hammerfest, Longyearbyen (78,049762N -15,458252E)) and they are spot on.”
In response to my question regarding his testing of the NOAACalculator versus the USNOCalculator he had an interesting and very practical answer
“We prefer to use USNO calculator as it is more in tune with the sunrise/sunset times printed in most newspapers. You see, our experience is that most users don’t look at the sun to determine sunrise/sunset but read the times in the newspaper. If our times don’t correspond to the printed ones, something is wrong with our system in their mind.”
A release candidate (RC1) of the Zmanim API 1.1 is now available on the download page. Changes in this release include a slight clean up of the recently releasedNOAACalculator code (does not change calculated times), as well as fixes to the date (but not time) of calculations for locations near the arctic circle. This date fix builds on the February release of the API to fix an arctic circle issue and a similar issue encountered when trying to generate zmanim for locations other than the local timezone. Also included in this release is the zmanimAstronomical-1.1.jar, a release that only includes the AstronomicalCalendar class and supporting classes. There was also some code refactoring to make the code easier to maintain. A detailed post will follow (hopefully within the next week or so).
I have been asked a number of questions recently about the directional accuracy of the Bearing to Yerushalayim and Zmanim Map calculations. The rhumb line calculations are very straight forward and I will not spend much time on it in this article. As a side note, for those interested in the subject, I would like to mention that Rabbi Gavriel Goetz recently published a very comprehensive pamphlet Gevuras Moishe on the subject and it is well worth reading. My original calculations and implementation of the great circle route (geodesic line) used simple spherical trigonometry to calculate the initial bearing (and distance) based on a sphere using an authalic mean radius of 6371 km. These calculations were very similar to the method used by Rabbi Yehuda Herskowitz’s article in Yeshurun volume III page 586. This model of the earth is more than accurate enough for these calculations (you would need a very accurate “nose alignment” and the total lack of shuckling to even get within a degree of being correct). Google Maps API, Yahoo Maps and Microsoft’s Live Maps for simplicity sake, all use very similar calculations as mentioned in the cfis blog (archived) quoting Morten Nielsen
Google Maps / Virtual Earth / Yahoo Maps(?) all use a spherical datum based on WGS84. That is, it has the same center, orientation and scale as WGS84, but has no flattening. The radius of the sphere is the same as the semi-major axis of WGS84 (6378137 meters).
6,371 km (authalic mean radius) sphere using spherical trigonometry
Google Maps API 6,378.137km (WGS84 equatorial mean radius) sphere using spherical trigonometry
As hinted at in my previous post , there is a new project underway that uses the Zmanim API in a way that I had never really imagined. Using the Smack API, Michael Kopinsky created the ZmanimBot that allows getting zmanim by instant messaging the ZmanimBot, an internet bot. It currently supports the Google Talk IM system, but support for other systems might follow. Please be aware that the system is under development and is not always up. Additional information can be found on the ZmanimBot page.
Update (April 13, 2008): The ZmanimBot is now available via AIM