Category: Software Dev

Tefila Rules Added to KosherJava Zmanim Library

Kosel Picture 1932
Davening at the Kosel. This picture was taken by my grandfather Sidney (Nesanel) Siegfried on Aug 1, 1932 כ״ח תמוז תרצ״ב. This article was posted exactly 90 years to the day (Gregorian date) after the picture was taken.
The new TefilaRules class has been added to the KosherJava Zmanim Library. This will be included in the upcoming v2.4.0 release. The TefilaRules class was added in an effort to help zmanim calendar authors who sometimes require knowing if תחנון tachanun is recited on a specific day in order to set tefila times (such as mincha starting X minutes before shkiah, and a few minutes later if tachanun is not recited). It is also useful for siddur app creators. With many different minhagim (mostly chasidishe) about when tachanun is recited, the class currently supports 12 different options that can allow setting the rules for a majority of minhagim.
Yahrzeits such as 7 Adar, (Moshe Rabbeinu’s yahrzeit) or holidays celebrated by specific communities such as Purim Mezhbizh (Medzhybizh) celebrated on 11 Teves or Purim Saragossa celebrated on the 17th of Shevat (the Wikipedia date seems to be in error), are not (and likely never will be) supported by this class.
Other tefila related rules such as the existing Mashiv Haruach etc. rules were moved over from the JewishCalendar class to this new class where they have a more natural fit. The methods that were migrated over, were deprecated in the JewishCalendar class and will be removed in v3.0.0.

Key Methods in the TefilaRules Class

The following are the key methods in the new TefilaRules class.

Sample Code

TefilaRules tr = new TefilaRules();
JewishCalendar jCal = new JewishCalendar();
HebrewDateFormatter hdf = new HebrewDateFormatter();
hdf.setHebrewFormat(true); // Hebrew formatting
jCal.setJewishDate(5783, JewishDate.TISHREI, 1); // Rosh Hashana
System.out.println(hdf.format(jCal) + " - Is tachanun recited: " + tr.isTachanunRecitedShacharis(jCal));
jCal.setJewishDate(5729, JewishDate.SHEVAT, 21);
System.out.println(hdf.format(jCal) + " - is mashiv haruch recited: " + tr.isMashivHaruachRecited(jCal));
jCal.setJewishDate(5783, JewishDate.ADAR, 17);
System.out.println(hdf.format(jCal) + " - Is tachanun recited: " + tr.isTachanunRecitedShacharis(jCal));
tr.setTachanunRecitedWeekOfPurim(false); //default is true
System.out.println(hdf.format(jCal) + " - Is tachanun recited: " + tr.isTachanunRecitedShacharis(jCal));

Output:

א׳ תשרי תשפ״ג - Is tachanun recited: false
כ״א שבט תשכ״ט - is mashiv haruch recited: true
י״ז אדר תשפ״ג - Is tachanun recited: true
י״ז אדר תשפ״ג - Is tachanun recited: false

NOAA Fixes Solar Calculator

When comparing the results of the KosherJava NOAA algorithm to the output of NOAA’s new Solar Calculator almost two years ago, a discrepancy was encountered between the two. There was no discrepancy compared to the output of the old NOAA calculator. The NOAA code is an implementation of the accurate Jean Meeus algorithm for solar time calculations, and the KosherJava code is a Java port of this algorithm. While attempting to debug the issue, I turned to Pinny Markowitz who ported the KosherJava library to both Ruby and Python. He was able to trace the issue to what seemed to be a small accuracy adjustment missing in the noon calculation on the new NOAA implementation. Based on Pinny’s analysis, the old implementation seemed correct, but without confirmation from the NOAA developers this was not a certainty. We reported the issue to NOAA for clarification, and after an almost two-year delay, the NOAA development team confirmed and corrected the bug. After NOAA’s fix there is no longer any discrepancy. The fix can be seen in line 342 of the NOAA JavaScript file, where a half day adjustment is made in the noon time calculation. This bug was never present in the KosherJava library, or other language ports of the KosherJava code, since our code was based on the original NOAA code.

Zmanim API 2.3.0 Released


The KosherJava Zmanim API version 2.3.0 was released on Dec 7th, 2021 ג׳ טבת תשפ״ב in Maven and GitHub. While there have been numerous releases over the years, this is the first release-related post since the v1.3.0 release in 2013. If you have not updated since that time, you can expect some changes. The most significant changes (besides a lot of new functionality) are the simple to fix breaking changes listed below.

New in Version 2.3.0

The list of significant changes in this and previous releases can be seen in the KosherJava Zmanim API changelog.

Breaking Changes since v1.3

Rav Moshe Feinstein’s Zmanim Added to the KosherJava Zmanim API


Rav Moshe Feinstein is of the opinion that chatzos is at a fixed time all year round and is calculated based on the location’s longitude (in Lakewood, NJ it is at 11:56am / 12:56pm during DST). See Igros Moshe Orach Chaim vol 4 no. 20 who states

והנה החצות לילה באמת לא משתנה כלל מימים הארוכים דקיץ לימים הקצרים חזודף אף לא לרגע אחד, למה שכתבתי בספרי אגדות משה על או״ח בסימן כ״ד שחצות היום הוא לעולם שוה שהוא כשבא השמש לאמצע הדרום וזה שוה בכל השנה רק ששני חצאי היום אינם שוים רק איזה ימים בשנה ולפעמים חצי הראשון גדול ולפעמים חצי השני גדול עיי״ש, וכן קבלתי גם מאבי מורי זצללה׳׳ה.

See the Igros Moshe for more details. The Aruch Hashulchan in Orach Chaim 233 no. 14 also calculates chatzos at a fixed time all year.

ודע דחצות היום תמיד שוה בקיץ ובחורף כשיכה המורה שעות י״ב אז הוי חצות היום וכן בלילה שהרי השעות שנתוספו או נתקצרו חציים מקודם חצות וחציים מלאחר חצות וא׳׳כ ממילא דהחצות לעולם עומדת בשוה

Rav Moshe also bases other zmanim calculations on this fixed local chatzos. As opposed to calculating shaaos zmaniyos from beginning to the end of a day, Rav Moshe calculates a number of zmanim based on half of the day starting or ending at fixed local chatzos (see Igros Moshe Orach Chaim vol 1, no. 23).

ומש״כ ידידי שהלוח של הישיבה אינו מדוקדק, הנה הוא בדיוק גדול ונכתב על דעתי. והטעם דהחצות של היום שהוא כשבא השמש באמצע הדרום שוה לעולם, אבל שני חצאי היום אינם שוים רק איזה ימים בשנה ולפעמים חצי הראשון גדול ולפעמים חצי האחרון. ולכן בין לקולא בין לחומרא מסתבר שנחלקו שש שעות עד חצות ושש שעות מחצות עד הערב. ולכן מש״כ ידידי שהוא שבשתא וטעות לא דבר נכונה שהוא אמת גמור וליכא ע״ז שום קושיא.

These zmanim are used in Mesivta Tiferet Yerushalayim (MTJ), Yeshiva of Staten Island and Camp Yeshiva of Staten Island. Code to calculate these Rav Moshe zmanim is now part of the latest v2.3.0 release of the KosherJava Zmanim API.
The following new zmanim are now included in the API:

Sample Usage

For developers, here is sample code that calculates the new zmanim. This should allow many zmanim apps to add Rav Moshe Feinstein’s zmanim with very little effort.

String locationName = "145 E Broadway, New York, NY";
double latitude = 40.7138;
double longitude = -73.9913;
double elevation = 11;
TimeZone timeZone = TimeZone.getTimeZone("America/New_York");
GeoLocation location = new GeoLocation(locationName, latitude, longitude, elevation, timeZone);
ComplexZmanimCalendar czc = new ComplexZmanimCalendar(location);
czc.getCalendar().set(1986, Calendar.MARCH, 23); //Rav Moshe's petirah
System.out.println("Sof zman shma alos 18° to fixed local chatzos: " + czc.getSofZmanShmaMGA18DegreesToFixedLocalChatzos());
System.out.println("Sof zman shma alos 16.1° to fixed local chatzos: " + czc.getSofZmanShmaMGA16Point1DegreesToFixedLocalChatzos());
System.out.println("Sof zman shma alos 90 to fixed local chatzos: " + czc.getSofZmanShmaMGA90MinutesToFixedLocalChatzos());
System.out.println("Sof zman shma alos 72 to fixed local chatzos: " + czc.getSofZmanShmaMGA72MinutesToFixedLocalChatzos());
System.out.println("Sof zman shma sunrise to fixed local chatzos: " + czc.getSofZmanShmaGRASunriseToFixedLocalChatzos());
System.out.println("Sof zman tfila sunrise to fixed local chatzos: " + czc.getSofZmanTfilaGRASunriseToFixedLocalChatzos());
System.out.println("Mincha gedola 30 minutes after fixed local chatzos: " + czc.getMinchaGedolaGRAFixedLocalChatzos30Minutes());
System.out.println("Mincha katana fixed local chatzos to sunset: " + czc.getMinchaKetanaGRAFixedLocalChatzosToSunset());
System.out.println("Plag hamincha fixed local chatzos to sunset: " + czc.getPlagHaminchaGRAFixedLocalChatzosToSunset());
System.out.println("Tzais 50 minutes after sunset: " + czc.getTzais50());

Calculating other fixed local chatzos based zmanim not included in the library (and not necessarily endorsed by this shitta) are very simple with the generic getFixedLocalChatzosBasedZmanim(Date startOfHalfDay, Date endOfHalfDay, double hours) method built to simplify calculating these zmanim. Here are a few examples.

//4 hours into a day based on half the day from alos 18° to fixed local chatzos
System.out.println("Sof zman tfila 18° to fixed local chatzos: " + czc.getFixedLocalChatzosBasedZmanim(getAlos18Degrees(), getFixedLocalChatzos(), 4); 
//plag hamincha based on the second half of the day starting at fixed local chatzos and ending 50 minutes after sunset
System.out.println("Plag hamincha fixed local chatzos to tzais 50 minutes: " + czc.getFixedLocalChatzosBasedZmanim(getFixedLocalChatzos(), getTzais50(), 4.75);

I would like to thank Avraham David Gelbfish who requested this addition and provided instructions on the proper calculations used by these yeshivos in calculating the zmanim.

FAQ: Location Precision for Zmanim Calculations

While overly broad ZIP code based zmanim geolocation can be an issue in calculating zmanim accurately, going overboard in geolocation precision and accuracy for zmanim is a (harmless) waste of time.
Let’s start with the basics. Asking what the zmanim are for the USA is too broad of a location. Narrowing it down to a state is also too broad since zmanim at one side of the state are likely to be different than the other side. How small (or precise) does an area have to be for the zmanim calculated to be considered accurate? The location of zmanim are calculated based on degrees of longitude (east to west) and latitude (north to south).

The earth’s circumference at the equator is about 40,000 km (about 25,000 mi). There are 360 degrees of longitude around the world (The 0° line is centered on the Royal Greenwich Observatory in England, and longitude lines extend 180° to the west and -180° to the east). For simplicity we will deal with longitude degrees at the equator. If we divide the earth’s circumference by 360°, each degree of longitude will be 111 km (69 mi) apart. The sun’s path travels 1° of longitude in 4 minutes, so calculating zmanim with one degree accuracy (no decimal points such as the latitude of 40° and longitude of -74° for Lakewood, NJ, a point in the Atlantic about 3 mi off the coast of Toms River, NJ) results in zmanim accurate to 4 minutes in each direction or an 8 minute spread, not quite accurate enough to rely on. Moving to one decimal point will pinpoint the location for zmanim calculation to an accuracy of 11 km or 48 second accuracy. That is close to being accurate enough, especially given the inaccuracy of solar time calculations resulting from hard to predict refraction caused by varying atmospheric conditions. However, this should be avoided. Adding a second decimal point (such as the latitude of 40.09° and longitude of -74.22° for Lakewood, NJ – a spot at the edge of Lake Carasaljo in Lakewood) would have a precision of about 4 seconds, more than enough accuracy for zmanim.
A concrete example of how zmanim differ from place to place in a small area would be the difference between Beth Medrash Govoha (BMG) and the Westgate Bais Medrash in Lakewood. They are 2.7 km (1.69 mi) or a drop more than 0.01° apart and calculations show that there is about a 6 second difference in sunrise and sunset times between these two locations.

From time to time I am contacted by developers with zmanim related technical questions. Debugging their issues often requires information on the latitude and longitude that they are using to try and replicate the issue. Often the latitude and longitude are sent with multiple decimal points. The most extreme was 14 decimal points. To understand the ridiculousness of this level of precision, see the table below. To read more on the subject, see the Stack Exchange page Measuring accuracy of latitude and longitude? and the xkcd cartoon on the subject.

Decimal places Degrees Distance Notes
0 1 111 km A state or small country
1 0.1 11.1 km City
2 0.01 1.11 km Neighborhood
3 0.001 111 m A specific cul-de-sac
4 0.0001 11 m A corner of a house
5 0.00001 1.1 m A person in a room
6 0.000001 11 cm A small siddur
7 0.0000001 1 cm The size of Waldo on a page
8 0.00000001 1 mm A grain of sand
9 0.000000001 111 μm The width of a hair
10 0.0000000001 11 μm A grain of pollen
11 0.00000000001 1 μm A smoke particle
12 0.000000000001 111 nm The width of a COVID virus
13 0.0000000000001 11 nm A red blood cell
14 0.00000000000001 1 nm The length your nails grow every second
15 0.000000000000001 100 pm An atom. If you need this precision, you probably belong in Lawrence Livermore