How do I get the Jewish Date for … using the Zmanim API?
The current version of the Zanim API does not support Jewish calendrical calculations. Zmanim are almost exclusively based on the solar calendar, so for example, the sunrise on February 8th this year in Montreal (or any other date and location), will be almost the same every year. for this reason there was little point (as far as zmanim) to support Jewish date calculations in the API. One of the only zmanim to rely on a Jewish date is the sof zman kidush levanah calculation, though there are some opinions that it is purely molad based, and this can be calculated without a Jewish calendar component to the API. This zman is obviously not currently implemented in the Zmanim API. I am currently working on adding Jewish date support to the API. The code is based off Avrom Finkelstein‘s no longer active HebrewDate project. I refactored a lot of the code and fixed a number of bugs. Anyone interested in alpha testing this code can download the latest Zmanim SVN code. I mentioned that it “will be almost the same every year” and this is due the the approximate 1/4 day drift between the 356 day calendar year and the approximately 365.25 days actually present in the astronomical year, a discrepancy corrected every leap year. A future FAQ (probably a few of them) may delve specifically into this drift as well as general zmanim accuracy issues in detail. If you are simply looking to convert a Hebrew date to Gregorian or Gregorian to Hebrew online without the API, try the JewishGencalendar conversion tools.
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 user contacted me with the following note (some details removed).
Could you please explain to me why there seems to be nearly a three minute discrepancy between the zemanim for XXXXX, NJ at 20 meters (exact location) and those listed for 20 meters on the MyZmanim.com site. Your site calculates 4/20 at 6:08:20 and theirs has it at 6:11:25….
I really can’t comment on the MyZmanim.com site since their code is not open source and I do not know the exact algorithm they use. The Zmanim Project code used here has 2 different algorithms available for calculating zmanim, one using the algorithm published by the USNO (US Navel Observatory), and the other from the NOAA (National Oceanic and Atmospheric Administration). I have 2 different implementations of the USNO algorithm (one has since been removed as a duplicate), and both return the exact time to the millisecond, so I believe that the code is a correct implementation of the USNO algorithm. You can look through the code at my site and see if you find any issues. Having said that, I did a comparison between MyZmanim.com and my site using the USNO algorithm and both sites are within seconds (all calculations were for April 19 for XXXXX, NJ):
Elevation in Meters
Based on this chart, the sunrise difference between KosherJava.com using USNO and MyZmanim.com who are probably also using the USNO algorithm is 3 seconds for sea level and 6 seconds at 20 meter elevation (see below for why the elevation calculation has this additional 3 second discrepancy). Keep in mind that while I was able to zoom in to the user’s exact location using the Google Map interface, myZmanim.com is using a zip code level calculation, and they might be calculating using a slightly different location. I believe that the times the user was referring to in his note were generated using the NOAA algorithm implementation. As mentioned above, At this point I have no information to indicate what algorithm is more accurate, and I will hopefully one day post more information on the accuracy of these algorithms.
As far as the elevation calculation, I use the formula
found in Calendrical Calcuations, as mentioned on the Zmanim Calendar Generator page. For this time of year and the XXXXX location and a 20 meter elevation returns a time 47 seconds earlier than sea level using my calculation, and 51 seconds earlier using myZmanim.com. I reran the calculation using the more commonly used but less accurate formula of
adding 0.0347 * squareRoot(elevationMeters) to the zenith
that is mentioned in the Maaglay Tzedek written by Rabbi Moshe Kosower (as mentioned in the JavaDocs and Calendar Generator page) and the difference between the 0 and 20 meter elevation was the same 51 seconds that appeared in MyZmanim.com. Besides relying on the more accurate calculation mentioned in Calendrical Calculations (considered the most authoritative book on calendars and astronomical time calculations), I spoke to Professor Moshe Koppel a few years ago about the subject and he validated the Calendrical Calculations algorithm (a seemingly common mathematical calculation). Looking back at the Maaglay Tzedek, it seems that this calculation includes changes to the refraction caused by the elevation, and I will have to research the subject some more. All this elevation difference boils down to an insignificant 3 second difference. Keep in mind that atmospheric refraction will have a much greater impact than this. Even if one were to know the exact atmospheric pressure, temperature and humidity, this varies in different parts of the atmosphere and would be extremely hard to calculate without measuring it at all elevations of the atmosphere. Please make sure to speak to a posek before using the time with elevation.
A lookup tool for elevation lookup was added to the Zmanim Calendar Generator page. This service is courtesy of Jonathan Stott’searthtools.org elevation webservice. This Elevation data currently only covers all of mainland Europe (between latitudes 35°N and 60°N and longitudes 35°E and 15°W) and all of the contiguous states of the United States of America (between latitudes 20°N and 50°N and longitudes 65°W and 125°W). The source of the data is:
The terrain model used to find heights above sealevel is from the Shuttle Radar Topography Mission (SRTM) which was a joint project between the US National Geospatial-Intelligence Agency (NGA) and the National Aeronautics and Space Administration (NASA). Data was recorded for 11 days from the Space Shuttle Endevour from 11th February 2000. The data used here is at a resolution of 3 arc seconds (approximately 90m).