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 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):

SiteAlgorithmElevation
in Meters
Sunrise
Time
MyZmanim.com?06:12:16
MyZmanim.com?206:11:25
KosherJava.comUSNO06:12:18
KosherJava.comUSNO206:11:31
KosherJava.comNOAA06:10:11
KosherJava.comNOAA206: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.

Zmanim Calendar Generator Does Not Yet Support 2007 DST Changes

Sunrise CalendarAs you may know, the U.S. is changing the Daylight Saving Time rules this year due to the Energy Policy Act of 2005. The server currently hosting this site does not yet have the Java patch for this. This means that from the second Sunday in March (the 11th) until the the last Sunday in March (the 25th), calendars generated from the Zmanim Calendar Generator will show the zmanim in standard time and not daylight savings time (DST). The same issue will happen in the fall from the last Sunday in October (the 28th) till the first Sunday in November (the 4th). The Java version used by the server should be patched within the next week or 2 to the latest Java 5 (JDK 1.5) version to solve this problem.

WordPress Hebrew Date Plugin Has a New Home

The Hebrew date Plugin has not been in active development for a while, and I am pleased to announce that it now has a new home at mikeage.net. Mike added a config page as well as a few new options. The plugin can be downloaded from the WordPress Hebrew dates Plugin Page. As a backup, you can also download it from Mike’s Site. In addition to Mike’s work, Jacob Fresco has used the code to create an additional Jewish Date plugin that displays the current Jewish date. This plugin has since been merged to Mike’s version.
Read the following posts at Mike’s site for more details.

Java Zmanim API Update

The first phase of change to allow easier porting to other languages took place with the change in the API from using inheritance of the Java Calendar classes, to one that uses composition. This will make porting it to other languages easier. Included in the update are a number of new zmanim, mostly the addition of a number of new calculations for plag that are useful when trying to avoid a tartai desasri with early erev shabbos minyanim.

Zmanim Calendar Generator Now using Google Maps

Vintage Map with CompassThe Zmanim Calendar Generator now has a simple way to look up longitude and latitude information using the Google Maps API. To use this feature, click on the Google Maps icon to display the map (location centered on Bais Medrash Gevoha in Lakewood), find the location that you want to generate zmanim for, and click that point in the map. This will update the longitude and latitude fields in the form. The Google API was pretty straight forward and simple. At the same time I tried to integrate an elevation lookup. Google does not provide elevation information, but I attempted to look it up using a webservice. This seemingly simple task was not very straight forward. The approach was to grab the SOAP response from the REST style elevation webservice made available by Jonathan Stott. My plan was to do this all via the client sided XML parsing. The first issue encountered was browser security that does not allow cross-domain loading of XML documents (By the way this was not using XMLHttpRequest, but the same security restrictions apply). This was solved by a simple PHP page that was just a proxy for the call. That done, I managed to get it to work in IE, but it crashed the browser every second call or so. The crashing was solved by adding a small delay. I never managed to get it working in Mozilla. I later tried to use the existing Google Maps API to load it, but never got it working. I commented out all elevation code, and will get to that part at some future date. I also removed the non decimal longitude and latitude option. I hope this will be useful.