Zmanim Calendar Generator Can Now Output Less Zmanim

Posted by KosherJava on May 18, 2009 - כ"ה אייר תשס"ט | Tagged as: Site News, Software Dev, Zmanim

After numerous requests, the Zmanim Calendar Generator can now output a less extensive list of zmanim. While the “full” calendar option (the default) generates an Excel spreadsheet with 108 columns of zmanim, the “standard” output generates a spreadsheet with 15 columns containing the most commonly used zmanim. The exact list of what constitutes commonly used zmanim is likely to be tweaked over time. The spreadsheet was initially designed for developers as a sample of the various zmanim available in the API . Developers can compare the output of their zmanim using the API, or a ported version of the API to the spreadsheet for accuracy. Based on feedback, many people use it to generate shul calendars, and wanted a less daunting list of zmanim.

Zmanim API 1.1 Released

Posted by KosherJava on March 27, 2009 - ג' ניסן תשס"ט | Tagged as: Site News, Software Dev, Zmanim

The Zmanim API 1.1 was released early this morning. Information about what changed in this release can be seen in previous posts about various beta and patch releases. A last minute change involved the removal of the misheyakir calculations commonly used by the Syrian community. The removal was due to the various different minhagim used, and Chacham Yosef Harari-Raful not endorsing any one, or including any, in his calendar. The API is flexible enough to be used for any calculation wanted by the various Syrian shuls even without “native” support for a built in “Ateret Torah” misheyakir. Some missing JavaDocs were also added.

I would like to again thank Rabbi Rachamim Ashkenazi the publisher of a zmanim calendar for the Syrian Community, and Victor Grazi for his input, testing and technical expertise used for adding the new “Ateret Torah” zmanim.

The main download is the Zmanim 1.1 release zip file that includes source files and JavaDoc documentation. Also available for download (included in the above zip file) is the main zmanim-1.1.jar and the new zmanimAstronomical-1.1.jar that only includes the AstronomicalCalendar and supporting classes. Additional detail on the downloads can be seen on the Zmanim Download page

Zmanim GUI Released

Posted by KosherJava on March 14, 2009 - י"ט אדר תשס"ט | Tagged as: Software Dev, Zmanim

I 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

Posted by KosherJava on February 25, 2009 - ב' אדר תשס"ט | Tagged as: Site News, Software Dev, Zmanim

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.

3 Native iPhone Zmanim Applications in the App Store

Posted by KosherJava on September 21, 2008 - כ"ב אלול תשס"ח | Tagged as: Software Dev, Zmanim

There are now 3 native iPhone programs in the iPhone App Store that display Zmanim. Pocket Luach from Tebeka Software, Zmanim from Avi Shevin and the iPhone Siddur from Rusty Brick. It is interesting to note that 2 out of the 3 use an open source Zmanim library. Zmanim uses Ken Bloom’s zmanim code (the optional ZmanimCalculator module in our Zmanim API uses a Java port of this code), and the iPhone Siddur uses a port of our own KosherJava Zmanim API (as mentioned in an email from the developer). With all of these available (and I am sure there are more to come), I am abandoning the iZmanim project to build a zmanim UI for the iPhone, since there is little need for it. My effort will concentrate on enhancing the API itself. I hope to be able to release the Rusty Brick Objective-C port of the API in the near future.

iZmanim - An Alpha Release of Zmanim for the iPhone

Posted by KosherJava on July 17, 2008 - ט"ו תמוז תשס"ח | Tagged as: Software Dev, Zmanim

The release of the iPhone 3G got me thinking about zmanim on the iPhone. While I would eventually like to create a free native iPhone zmanim app, for now I created a simple iPhone web app to test out the UI. While only of alpha quality, the iZmanim web app should properly work on an iPhone (tested in Safari on Windows and iPhone emulators). These is a settings page that persists changes made. The iZmanim web app was built using the iUI framework. iZmanim can be tested with any Webkit browser. For the full effect, try it using the iPhone Tester on Safari. Please note that it will not properly load in IE or Firefox.

If any Cocoa/Objective C/iPhone developers would like to give a hand in developing the native iZmanim, please contact me.

Zmanim API 1.1 Beta 2 Released

Posted by KosherJava on July 17, 2008 - ט"ו תמוז תשס"ח | Tagged as: Software Dev, Zmanim

The second beta release of the Zmanim API 1.1 is now available on the download page. Changes in this release include additional code refactoring to the refactoring already done in the last few releases. As in the previous release, included is the zmanimAstronomical-1.1_beta_2.jar, a release that only includes the AstronomicalCalendar class and supporting classes. As part of the changes, an effort was put in to make the code simpler to port to other languages. This mostly involved moving formatting code out of main classes. The only interface changes were the addition of a few new methods to the GeoLocation class. It is likely that the next release will remove the empty GeoLocation constructor that can lead to inadvertent errors. This removal might break existing code. I hope to post details about these changes in the near future.

Zmanim Bug Report from the Land of the Midnight Sun

Posted by KosherJava on May 8, 2008 - ד' אייר תשס"ח | Tagged as: Software Dev, Zmanim

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.”

Zmanim API 1.1 Release Candidate Available

Posted by KosherJava on April 17, 2008 - י"ג ניסן תשס"ח | Tagged as: Software Dev, Zmanim

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

Posted by KosherJava on April 13, 2008 - ט' ניסן תשס"ח | Tagged as: Software Dev, Zmanim

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. Both produce identical zmanim using slightly different code and are included for comparison. There is also the JSuntimeCalculator, 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.

Older Entries »