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.

## Equinox VS Equilux in Zmanim Calculations

## Degree based *Zmanim*

Degree-based *zmanim* are considered most accurate by many *poskim* since *zmanim* calculated using degrees for *alos* and *tzais* have a consistent level of light at all dates and locations. The alternatives of using fixed minutes (for example 72 minutes) or percentage of the day-based calculations (1/10^{th} of the day) result in *alos* and *tzais zmanim* having different levels of light at different dates and locations. The number of degrees for a given *zman* is calculated based on how many degrees the sun is below the horizon on an equal day in Yerushalayim^{[1]}. For example, the sun is 16.1° below the horizon 72 minutes before sunrise (or after sunset)^{[2]} on an equal day (defined below) in Yerushalayim. The subject of degree-based *zmanim* is extensive and deserves its own detailed article, עוד חזון למועד.

## Equinox VS Equilux in Halacha

A question explored by *poskim* and *luach* authors is; how we define an equal day to use for degree-based *zmanim* calculations. Should it be calculated at the astronomically equal day of the equinox or the *halachic* equal day of the equilux^{[3]}. At the equinox, the 12-hour duration of the day is calculated astronomically without accounting for refraction or solar radius^{[4]}. At the equilux there are exactly 12 hours of daylight from sunrise to sunset. Due to these two factors, the *halachic* length of the day from sunrise to sunset at the equinox is longer than 12 hours. In Yerushalayim on March 20, 2021, the day of the March equinox, sea level sunrise is at 5:42:51 AM and sunset is at 5:50:33 PM, or a day length of 12 hours, 7 minutes and 42 seconds. You would have to go back four days^{[5]} to March 16, the equilux, for a 12-hour day^{[6]}. There are *halachic* opinions supporting both the equinox and the equilux as the equal day for *zmanim* calculations^{[7]}.

## Practical Differences Between Equinox and Equilux Calculations

Many calendars and *seforim* list the 72-minute *alos / tzais* as 16.1° and 90 minutes as 19.8° (using the global refraction average + solar radius of 0.8333). Calculations using the KosherJava *Zmanim* API (utilizing the Jean Meeus / NOAA algorithms) show that the actual figures are 16.08° and 19.848° at the equilux, and 16.04° and 19.784° at the equinox. The table below shows the difference between these numbers at the summer solstice when twilight is the longest (the most extreme expected gap between two different degree-based times).

Difference Between the Equilux and Equinox Calculations at the Summer Solstice | ||||
---|---|---|---|---|

Location | 7.199° VS 7.205° (30 Min)^{[8]} | 11.424° VS 11.442° (50 Min) | 16.04° VS 16.08° (72 Min) | 19.784° VS 19.848° (90 Min) |

Jerusalem Lat: 31.7° | 2 sec | 7 sec | 15 sec | 26 sec |

Lakewood Lat: 40.1° | 2 sec | 7 sec | 20 sec | 38 sec |

Montreal Lat: 45.5° | 3 sec | 10 sec | 30 sec | 90 sec |

Krakow Lat: 50.05° | 3 sec | 13 sec | 93 sec | N/A |

London Lat: 51.5° | 4 sec | 16 sec | N/A | N/A |

Vilnius Lat: 58.68° | 13 sec | 47 sec | N/A | N/A |

Anchorage Lat: 61.2° | N/A | N/A | N/A | N/A |

N/A indicates that the sun does not get this far below the horizon at this time of the year due to the high latitude of the location. See Why Some Zmanim Never Occur for more details. |

While the above question is interesting from an academic perspective, the measurements above show a negligible difference between calculating at the equinox VS the equilux for most locations and *zmanim*. The difference in calculating *zmanim* up to 16.1° *alos / tzais* on the equinox vs the equilux isn’t significant until the 30 second difference at the 72-minute *zman*. Since this is typically calculated as 16.1° *lechumra*, there is no difference at all for this *zman*. The less commonly used 19.8°, has an up to 90 second difference (at the latitude of Montreal). The ~11.5° *misheyakir* times start showing a difference at high latitudes. This is not significant even as far north as London but becomes significant at the 58.68° latitude of Vilna (Vilnius) since it reaches 47 seconds.

## Observations on Degree Based Calculations

- The commonly used 16.1° time is a slightly rounded
*chumra*for both the equinox and equilux. The actual numbers are 16.04° and 16.08°. - The 19.8°
*zman*mentioned by many calendars and*seforim*is calculated at the equinox where it is 19.784° and not equilux where it is 19.848°. It should possibly be rounded up to 19.9°*lechumra*to account for the equilux calculation^{[9]}. - The
*misheyakir*11.5° times are a slight*kula*since both the equilux (11.442°) and the equinox (11.424°) calculations show a sightly later time. - As noted above, the degree-based calculations were done using the more accurate Jean Meeus / NOAA algorithms.
*Seforim*printed in the past did not have access to the newer algorithms and typically used the USNO algorithm, but as seen below, there is only a trivial difference between the algorithms.*Zman*Equinox Equilux USNO NOAA USNO NOAA 30 Min 7.203° 7.199° 7.208° 7.205° 50 Min 11.432° 11.424° 11.449° 11.442° 72 Min 16.055° 16.04° 16.092° 16.08° 90 Min 19.804° 19.784° 19.865° 19.848°

##### Notes:

1. ^{^} The assumed location for these calculations in most calendars (and the KosherJava *zmanim* library) is Yerushalayim, something that is debatable. See Hazmanim Bahalacha 19:2, pages 169-170.

2. ^{^} As an example, *alos hashachar* according to some opinions is 72 minutes before sunrise (the time it takes to walk 4 *mil* at a speed of 18 minutes per *mil*). The time of twilight from *alos* / dawn to sunrise and sunset to *tzais* / night is known as *neshef* נשף in Hebrew. The time of twilight differs by location and time of year with the longest duration during the summer solstice, shortest by the equinoxes and somewhere in between in the winter. According to many opinions this *zman* should be calculated by measuring the sun’s degrees below the horizon at the equal day and applying the same number of degrees to any location and date.

3. ^{^} A term coined by astronomers in the 1980s and in “popular” use since ~2006.

4. ^{^} It is calculated as if the world had no atmosphere and the radius of the sun is above the horizon.

5. ^{^} Rabbi Yedidya Manat mentions that there are 5 to 6 days separating the equinox and equilux, while Rabbi Yonah Merzbach in a letter to Rabbi Manat mentioned a week or two. Calculations show the difference between the equinox and equilux to be 4 days in Yerushalayim, moving the calculation date from March 20^{th} back to March 16^{th} (or from September 22^{nd} to the 26^{th}).

6. ^{^} In March 2021 it is 8 seconds off from a true 12-hour day due to the location where the equinox occurs for that season (it is at a single point and time globally), but it is more than close enough for our purposes. The figure varies from year to year. Calculations on the September equinox show similar results.

7. ^{^} Rabbi Meir Pozen in his Kuntres Haneshef and Or Hameir, is of the opinion that the equilux should be used. Opinions that the equinox should be used are brought down by Rabbi Yedidya Manat in his Zmanei Halacha Lema’aseh (4^{th} edition part 2, pages 22 and 24), Rabbi Yonah Merzbach (in a letter published by Rabbi Manat) and Rabbi David Yehuda Burstein in his Zmanim Kehilchasam, 1:8 (pages 56 – 61). This is also the opinion of Rabbi Chaim Pinchas Banish in Hazmanim Bahalacha vol 1, 19:3, page 270, and Rabbi Aryeh Leib Lipkin in his Ohr Hayom, summary section, no. 9 (page 76).

8. ^{^} This is close to the 7.083° *tzais zman* and used for comparison. The 7.083° *zman* was first brought down by Dr. Baruch (Berthold) Cohn in his *luach* Tabellen enthaltend die Zeitangaben für den Beginn der Nacht und des Tages für die Breitengrade + 66 bis -38, published in Strasbourg, France in 1899. It was based on actual observation of star visibility. Some list the 7.083° *zman* as based on the 30-minute calculation, but as seen in the chart, it is not an exact match. In Yerushalayim at the equinox (when there is the smallest difference), 7.083° is 33 seconds earlier than the 30-minute time of 7.199° and in Vilna it is 49 seconds earlier. At the solstice in Yerushalayim 7.083° is 39 seconds earlier than 7.199°, and in Vilna it is 97 seconds earlier.

9. ^{^} At this point the KosherJava *Zmanim* API will continue using the 16.1° (a minor *chumra*), and 19.8° (a minor *kulah* at the equilux) used by the Yisrael Vehazmanim and many others.

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

- Added seasonal
*davening*based*zmanim*including*Vesein Tal Umatar/ Vesein Berachah / Mashiv Haruach*. - Added Rav Moshe Feinstein’s fixed local
*chatzos*based*zmanim*. These are used in MTJ and Yeshiva (and Camp) of Staten Island. - Refactored code for
*alos*and*tzeis zmaniyos*based time (ports of the library to other languages can simplify their code by doing the same). - Fixed an issue with
*kiddush levana*being off by an hour when the*molad*and*kiddush levana zmanim*are on different sides of the DST change. This impacted the JewishCalendar but not the ComplexZmanimCalendar. - Corrected the Hebrew spelling of
*Parshas Nitzavim*.

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

## Breaking Changes since v1.3

- The Zmanim API no longer supports Java versions prior to Java 8 (released in March 2014). It likely still compiles against Java 6 released in December 2006.
- The package structure changed from net.sourceforge.zmanim to com.kosherjava.zmanim.
- There were two mathematically identical calculators using the USNO algorithm, so the less clean (code-wise) ZmanimCalculator was removed, while the SunTimesCalculator was retained.

## 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 for more details. The Aruch Hashulchan 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:

*Sof zman shma alos*18° to fixed local*chatzos**Sof zman shma alos*16.1° to fixed local*chatzos**Sof zman shma alos*90 minutes before sunrise to fixed local*chatzos**Sof zman shma alos*72 minutes before sunrise to fixed local*chatzos**Sof zman shma*sunrise to fixed local*chatzos**Sof zman tfila*sunrise to fixed local*chatzos**Mincha gedola*30 minutes after fixed local*chatzos**Mincha ketana*fixed local*chatzos*to sunset*Plag hamincha*fixed local*chatzos*to sunset*Tzais*50 minutes after sunset

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