The Zmanim API was developed from the ground up as an API which allows for easy plugging in of different algorithms. The Zmanim API ships with 3 “Calculator” implementations. Two calculators implement the US Naval Observatory’s algorithm, the SunTimesCalculator and the ZmanimCalculator (no longer available). Both produce identical zmanim using slightly different code and are included for comparison. There is also the JSuntimeCalculator (no longer available – see below information on the NOAACalculator), an implementation of the NOAA algorithm by Jonathan Stott. I was recently contacted by Eliezer Bulka who wanted to know why sunrise/sunset times generated by the NOAA algorithm were about 2 minutes off of the sunrise/sunset times generated by the NOAA JavaScript implementation that is the source of the JSuntimeCalculator. To compare apples and apples required modification of the NOAA JavaScript to allow entry of decimal latitude/longitude and changing the output to display seconds. No change was made to the algorithm itself. I then ported the JavaScript directly to Java. This involved nothing more than slight syntax changes between the languages. Once this was done, I noticed that the sun rise/set output from the Java port exactly matched the output of the NOAA JavaScript. Analysis of Jonathan’s code showed (or at least my interpretation of it did) that there were two areas that caused the difference. Once is that he used a slightly different method of computing the Julian date, a key part of the algorithm. His change includes the time of day as part of the calculation. The net result of this change is that solar time generated using his algorithm varies based on the time of day the calculation is run, something that is incorrect. This means that there can be a discrepancy of up to one calendar day. If the user calculated sunrise at 11:59 PM, sunrise would be calculated for the following day even if the user attempted to calculate it for today. In addition, the other calculations do not match the output of the matching NOAA code. I have deprecated the JSuntimeCalculator and in its place added the NOAACalculator that was the result of the direct port of the NOAA code, shoehorned into the Zmanim API Calculator interface. I ran some tests to compare the maximum and minimum discrepancy between the 2 implementations, and calculations for Lakewood, NJ, latitude 40.0828, longitude -74.2094 show a discrepancy of between a minute and 34 seconds to a minute and 37 seconds for sunrise and sunset across an entire year of sunrise and sunset calculations. I also compared the USNO algorithm to the new NOAA implementation and ended up with a maximum deviation of less than 30 seconds, something that had been about 1.5 minutes apart previously. While I do believe that the Julian date calculation is a bug, I do not know that this is a case as far as the rest of the calculation, but it is clear that it does not match the NOAA implementation that is was based on, and I recommend that you download the latest version that has the new NOAACalculator that fixes this issue. In addition to this fix, an additional patch will be released later this week that will address issues with calculations in the arctic circle. Stay posted for the next post.
Tag: Zmanim Accuracy
Calculation of Zmanim VS Other Sites
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 Naval 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):
| Site | Algorithm | Elevation in Meters |
Sunrise Time |
|---|---|---|---|
| MyZmanim | ? | 0 | 6:12:16 |
| MyZmanim | ? | 20 | 6:11:25 |
| KosherJava | USNO | 0 | 6:12:18 |
| KosherJava | USNO | 20 | 6:11:31 |
| KosherJava | NOAA | 0 | 6:10:11 |
| KosherJava | NOAA | 20 | 6:09:24 |
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
zenith = zenith + Math.toDegrees(Math.acos(earthRadiusInMeters / (earthRadiusInMeters + elevationMeters)));
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.
Elevation Lookup Added to Zmanim Calendar Generator
A lookup tool for elevation lookup was added to the Zmanim Calendar Generator page. This service is courtesy of Jonathan Stott’s earthtools.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).
The lookup is done via an AJAX call.