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 (since replaced by the SunTimesCalculator) module in our Zmanim API uses a Java port of Ken’s 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.
Author: Eliyahu
iZmanim – An Alpha Release of Zmanim for the iPhone
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 (no longer available) 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
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
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
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).