## 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

## Taanis Bechoros Added to the KosherJava Zmanim API

Years ago I posted the Calculating Erev Pesach Zmanim that discussed the addition of sof zman achilas chametz and sof zman biur chametz times to the API. Based on a request on the KosherJava project’s GitHub repository, a new isTaanisBechoros() method was added to the API. The Taanis Bechoros fast day usually occurs on Erev Pesach, but in years like this year (5781/תשפ״א – 2021) when Erev Pesach occurs on Shabbos, the fast is moved back to Thursday the 12th of Nissan. Erev Pesach occurs on Shabbos an average of once every 10 years. The frequency of such occurrences ranges from 3 to 20 years. It will next occur in the year 5785/תשפ״ה – 2025, followed 20 years later in the year 5805/תת״ה – 2045. The code is included in the new v2.2.0 release of the KosherJava zmanim library. The following code sample shows the basic usage of the new method.

JewishCalendar jd = new JewishCalendar();
HebrewDateFormatter hdf = new HebrewDateFormatter();
jd.setJewishDate(5781, JewishDate.NISSAN, 12);
System.out.println(jd.isTaanisBechoros());

Output:

true

## Decimal Versus Sexagesimal Based Zmanim Location Errors

There are two different ways to reference latitude and longitude. One uses a sexagesimal (60 based) system of degrees indicated by a ° symbol, minutes indicated by a ' and seconds indicated by ". Think 60 minutes in an hour, 60 seconds in a minute and apply it to latitude numbers. The other system uses the more familiar decimal based format. For example The main BMG beis hamedrash is located at latitude 40.096, longitude -74.222 in degree/decimal. In degrees, minutes and seconds this would be latitude 40° 5′ 46″ N, longitude 74° 13′ 19″ W.

I was recently shown a zmanim calendar that seemed to be slightly inaccurate. Researching the issue showed that the intention was to generate the calendar for the location XX° 46′ N XX° 15′ W (latitude and longitude degrees are masked), but was mistakenly calculated for XX.46° -XX.15°. This confusion of the sexagesimal based system with the decimal based system is not uncommon. The discrepancy in sunrise and sunset in the calendar versus what it should have been was about 80 seconds in the summer. If someone were to confuse XX° 9′ with XX.9° (for both latitude and longitude) you have a much more significant relative error of 0.75°. The impact of this type of mistake is mostly caused by longitude, but latitude changes impact zmanim calculations as well. This 0.75° mistake can result in a zmanim discrepancy of up to five and a half minutes at the latitude of Lakewood, NJ. As confirmed by Dr. Noson Yanofsky, this scenario has the most extreme error, while 10′ confused with 0.10° has the least significant error of 0.066°.

An interesting variant of such a mistake is calculating a zman for a depression angle (how far the sun is below the horizon) that is based on degrees and minutes using degree/decimal. An example is mistakenly calculating tzais of 7° 5′ , or 7.083° as 7.5°. See Hazmanim Bahalacha vol II p. 520 footnote 21 for a case where this mistake happened. It should be noted that some are of the opinion that a depression angle of 7.5° is the proper time of tzais. This was used in the first ever known printed calendar calculated based on depression angles. It was published in תקכ״ו / 1766 by Raphael Levi Hannover. See Hazmanim Bahalacha p. 524 for a picture of the luach and a list of other calendars that calculate tzais as 7.5°.

To answer the question in the image caption above, the time in a regular 12 hour / duodecimal based clock would be 7:40. With 10 hours instead of 12, each decimal hour on this clock is 72 minutes of regular time. Therefore 6 hours = 432 minutes. Add ~19/50 decimal minutes that are equivalent to ~28/72 regular clock minutes and you end up with 460 minutes after noon/midnight, or about 7:40 🙂.

## The Yereim’s Bein Hashmashos

Rabbi Eliezer of Metz (known by his acronym The רא״ם Re’em), a disciple of Rabbeinu Tam, in his Sefer Yereim ספר יראים chapter 274, states that bein hashmashos starts the time it takes to walk three quarters of a mil before sunset, and ends at sunset.

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

The Yereim’s opinion is brought down by other Rishonim including the Mordechai and Rav Alexander Suslin HaKohen in his Sefer Agudah. The Yereim is mentioned by the Bach as a reason for the minhag of starting Shabbos early. The Yereim’s times are not brought down by the poskim lehalacha.

## The Time to Walk a Mil

The time to walk a mil is based on the Gemara in Pesachim 93b – 94a. The time ranges in the poskim and includes 18, 22.5 and 24 minutes. Three quarters of these mil times would be 13.5, 16.875 and 18 minutes. It should be noted that the Yereim is of the opinion that a mil is 24 minutes. The above mentioned Mordechai who quoted the Yereim is also of the same opinion. We will hopefully discuss in detail the various opinions on the time to walk a mil in a future article.

## The Addition of the Yereim’s Times to the KosherJava Zmanim Library

As of the 2.1.0 release of the KosherJava zmanim library, the Yereim’s bein hashmashos times have been added to the KosherJava zmanim library/API. There are six variants of these zmanim that were added. These include the three exact minute offsets mentioned above, as well as the conversion of these three times to degrees (elevation angle, or solar zenith angle). The only prior degree based time for the Yereim that I am aware of is in Rabbi Yedidya Manet’s Zmanei Halacha Lema’aseh (זמני ההלכה למעשה מהרב ידידיה מנת). The Zmanei Halacha Lema’aseh charts calculate bein hashmashos in degrees based on the 18 minute (3/4 of a 24 minute mil, see p. 27 in the 4th ed. published in 2005), but does not clarify the degrees used. At Rabbi Yaakov Shakow’s recommendation, I used the refraction value of 31/60 or 0.516° that exists in Israel, as opposed to the global average of 0.566°. This more stringent refraction is mentioned in the Zmanei Halacha Lema’aseh (p. 11) and used in the לוח עתים לבינה Luach Itim Lebinah. I also slightly rounded the times. These small tweaks resulted in a trivial maximum 19 second chumra vs the non-rounded global average refraction. The resulting degrees of elevation angle for the Yereim’s bein hashmashos are 2.1°, 2.8° and 3.05°. Solar zenith angles are traditionally calculated using the sun’s position without adjusting for refraction and without accounting for the solar radius (i.e. it is the position of the center of the sun in a vacuum). This does not impact the calculated time, it is simply the convention used. In the upcoming 8th edition of הרב דוד יהודה בורשטין Rabbi Yehuda Burstein’s זמנים כהלכתם / Zmanim Kehilchasam he mentions that

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

A future article will address the proper date to use for converting minute-based times to degrees below (or above) the horizon and show how to use the KosherJava Zmanim code to calculate this.
I would like to thank Rabbi Yaakov Shakow for his help and suggestions.

## Sample Code

Below are code examples for all six variants of the Yereim’s Bein Hashmashos (spelled BainHashmashos in the code).

GeoLocation yerushalayim = new GeoLocation("Jerusalem, Israel", 31.778, 35.2354, 0, TimeZone.getTimeZone("Asia/Jerusalem"));
ComplexZmanimCalendar czc = new ComplexZmanimCalendar(yerushalayim);
Date bh18Min = czc.getBainHasmashosYereim18Minutes();
Date bh3Pt05Deg = czc.getBainHasmashosYereim3Point05Degrees();
Date bh16Pt875Min = czc.getBainHasmashosYereim16Point875Minutes();
Date bh2Pt8Deg = czc.getBainHasmashosYereim2Point8Degrees();
Date bh13Pt5Min = czc.getBainHasmashosYereim13Point5Minutes();
Date bh2Pt1Deg = czc.getBainHasmashosYereim2Point1Degrees();

SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd h:mm:ss a z"); //set the output format
sdf.setTimeZone(czc.getGeoLocation().getTimeZone()); //set the formatter's time zone
System.out.println("Bein Hashmashos 18 min:     " + sdf.format(bh18Min));
System.out.println("Bein Hashmashos 3.05°:      " + sdf.format(bh3Pt05Deg));
System.out.println("Bein Hashmashos 16.875 min: " + sdf.format(bh16Pt875Min));
System.out.println("Bein Hashmashos 2.8°:       " + sdf.format(bh2Pt8Deg));
System.out.println("Bein Hashmashos 13.5 min:   " + sdf.format(bh13Pt5Min));
System.out.println("Bein Hashmashos 2.1°:       " + sdf.format(bh2Pt1Deg));

The output of the above code (assuming that the calendar was set to March 16, 2020).

Bein Hashmashos 18 min:     2020-03-16 5:29:58 PM IST
Bein Hashmashos 3.05°:      2020-03-16 5:29:40 PM IST
Bein Hashmashos 16.875 min: 2020-03-16 5:31:05 PM IST
Bein Hashmashos 2.8°:       2020-03-16 5:30:51 PM IST
Bein Hashmashos 13.5 min:   2020-03-16 5:34:28 PM IST
Bein Hashmashos 2.1°:       2020-03-16 5:34:09 PM IST

## KosherJava Zmanim Library Package Name and Build Process Update

The KosherJava zmanim library originally went live in 2004. There was an existing C/C++ zmanim project by Ken Bloom hosted on SourceForge (that was at the time the equivalent of what GitHub is today). The Java package structure name net.sourceforge.zmanim was based on the one used by Ken’s project (despite not being hosted there), and remained that way for 16 years.
On August 3, 2020, Eli Julian modernized the library’s build process from the previously used Ant, to Maven & Gradle. This change simplified the workflow for many developers using the zmanim API. As part of the change, the package name was updated to com.kosherjava.zmanim. The KosherJava zmanim Maven / Gradle artifacts are available at the KosherJava zmanim Maven Central page. A direct Jar download is available at Maven Central (see the KosherJava Downloads page for instructions). The old code was branched into zmanim-1.5 and will allow people who do not want to upgrade to continue to use the old structure (and Ant build process) while continuing to receive emergency bug fixes. This will allow the codebase to use more modern Java language features, without impacting users who want to remain on the legacy code. The new code has a minimum Java 8 requirement (a version released in March 2014). Releases based on the new build process will use SemVer (Semantic Versioning) to make things simpler for developers.
The upgraded build process also allowed automated GitHub’s CodeQL vulnerability scanning for the KosherJava Zmanim project.

<dependency>
<groupId>com.kosherjava</groupId>
<artifactId>zmanim</artifactId>
<version>2.0.3</version>
</dependency>