Moshe Wagner who wrote the Zmanim GUI notified me in August that that he created a command line interface for zmanim using my Zmanim API. The technical approach of using reflection was similar to the way I used reflection in the Zmanim Clock Applet, but he took it to new heights. Sample use of accessing zmanim using his CLI interface is:
moshe@debian:~/Desktop$ java -jar ZmanimCLI.jar
Usage: ZmanimCLI [options] [Time]
-d --date <yyyy/mm/dd> Set date. (Year first!)
-lat --latitude <latitude> Set location's latitude
-lon --longitude <longitude> Set location's longitude
-e --elevation <elevation> Set location's
elevation; Positive only
-tz --timezone <timezone> Set location's TimeZone
-h --help Show this help
-stl --time-list Show common available
times to display
-ftl --full-time-list Show all available
times to display
-tzl --timezone-list Show available timezones
ZmanimCLI --latitude 31.7780 --longitude 35.235149 --elevation
600 --timezone Israel Sunrise
Will show the sunrise time today in Jerusalem
While your first reaction may be that it is interesting in a theoretical geeky way, but has no practical value, I will quote Moshe’s explanation as to why it is useful:
Why is this useful? Well, first of all it was a nice experiment. But mainly, you can now use Zmanim (although externally), via any language you want, no longer being tied to Java.
Months later, Moshe actually put this to practical use in his C++ based Luach project. This Luach (similar to the known Kaluach) uses the Qt framework. utilizing libhdate for the date stuff (something not offered by the Zmanim API, and the topic of a future Zmanim API FAQ), displaying zmanim using the Zmanim API via CLI for the zmanim calculations. While you would expect such an approach to be slow, using the Luach seemed almost instantaneous. I will post more about his Luach program (recently reviewed at KosherDev.com) at some point in the future.
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 patchreleases. 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.
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 variousprogramsthat douse the API, there is no standalone JavaGUI 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.87updated on May 12, 2009). Questions and comments can be posted here, or sent directly to Moshe at moshe.wagner -AT- gmail.com.
As hinted at in my previous post , there is a new project underway that uses the Zmanim API in a way that I had never really imagined. Using the Smack API, Michael Kopinsky created the ZmanimBot that allows getting zmanim by instant messaging the ZmanimBot, an internet bot. It currently supports the Google Talk IM system, but support for other systems might follow. Please be aware that the system is under development and is not always up. Additional information can be found on the ZmanimBot page.
Update (April 13, 2008): The ZmanimBot is now available via AIM
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 surnise 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.