Zmanim GUI Released

Java Logo Sepia
Zmanim GUI screenshotI was recently contacted by Moshe Wagner who wanted to know if there was a graphical front end to the Zmanim API. While there are various programs that do use the API, there is no standalone Java GUI that uses the API (the zmanim clock applet is not easily useful for looking up zmanim for various locations). As first announced in Hebrew (ZmanimGUI – ממשק להצגת זמני היום ההלכתיים), Moshe took the API and wrote a Java Swing GUI for the API. The Zmanim GUI (called זמני היום in Hebrew) can switch between Hebrew and English display and shows the most common list of zmanim typically used. The program requires Java 6 and can be launched by double clicking on the ZmaniGui jar file (or execute the command ‘java -jar ZmaninGui.jar’ from a command prompt). As with the Zmanim API, the GUI was released under the GPL2 and is available (including source) on our download page (direct link to version 0.0.87 updated on י״ח אייר תשס״ט May 12, 2009). Questions and comments can be posted here or sent directly to Moshe at moshe.wagner -AT- gmail.com.

Zmanim API 1.1 Beta 3 Released

The third beta release of the Zmanim API 1.1 is now available on the download page. The main change in this release is the addition of zmanim based on the psak of Chacham Yosef Harari-Raful of Yeshivat Ateret Torah. These zmanim were requested by members of the Syrian Community. Other changes in this release include various additions and fixes to the API JavaDocs. I hope to post some detailed information about the new “Ateret Torah” zmanim in the near future. I would like to thank Rabbi Rachamim Ashkenazi the publisher of a zmanim calendar for the Syrian Community for his help with the “Ateret Torah” zmanim.

The main download is the Zmanim 1.1 beta 3 release zip file including source files and documentation. Also available for download (included in the above zip file) is the main zmanim-1.1_beta_3.jar and the new zmanimAstronomical-1.1_beta_3.jar that only includes the AstronomicalCalendar and supporting classes.

Zmanim API 1.1 Release Candidate Available

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 released NOAACalculator 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).

Fix to NOAA Sunrise/Sunset Algorithm

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.

Updated Zmanim Jar Released – Please Download the Latest

In December when developing the Zmanim / Bearing to Yerushalayim map (blog post), I noticed a problem with the code used to generate zmanim. The API returns a Java Date object. Usually only the time is of interest, and the date is ignored, but in some cases (when a timezone offset is specified without using the Olson DB name (such as America/New_York) or if the GMT timezone is used for other locations, and the local standard time is calculated as an offset of GMT), the date of the sunset returned was earlier than the sunrise date. This caused zmanim such as sof zman Shema for some locations to be incorrect, since the math used was comparing sunrise to a sunset on the incorrect date, causing some very odd behavior. Updated files that correct this issue were uploaded to the site on Dec 26th. I was notified today by a developer using the jar, that not all the download links were pointing to the updated versions, and this caused issues for his program (a post about his project will be posted in the near future). All the links have now been updated. Since the old code can sometimes generate incorrect zmanim, it is highly suggested that you replace your current jar with the latest version of zmanim.jar (or zmanim.zip).

Along with the fix mentioned above, a number of other small fixes were done. These include among other minor issues, fixed, better and simplified XML output from the toString method, better error handling for expected error conditions, that had previously caused errors in the generations of zmanim for areas in the arctic circle such as Thule, Greenland. In case you are curious, someone did actually try this, and the error logs lead me to find the issue. The IP address used for the request mapped back to the Thule Air Base.