KosherJava Powers Zmanim on El Al Flights

In an earlier Inflight Zmanim Calculations – Why So Complex? post, I outlined the complexity of calculating zmanim for flights. Back in Aug 2022, Dan’s Deals posted the exciting news that Zmanim were added to El Al’s flight entertainment system. This had not been formally announced by El Al at the time since the app was really in an (unannounced) alpha/beta testing phase. A careful examination of the screenshots by members of the #zmanim channel in the Frum Software Developers Slack, showed that it was powered by the KosherJava zmanim library. It should not have been surprising that it was found and used without my knowledge, since it is a free, well documented and easy to use open source library. After a number of issues with the zmanim app were reported to me (I want to thank all of those who took the time to track me down to report the issues), Rabbi Dovid Heber reached out to El Al, and Tal Kalderon, the head of El Al’s Inflight entertainment & Connectivity team reached out to me for assistance. This lead to meetings with Boris Veksler the CEO of FlightPath3D who integrated the KosherJava zmanim code into their flight maps as an optional module that El Al is using.

The FlightPath3D in-flight mapping app on El Al with the zmanim app Magen Dovid icon on the bottom left
Boris made it a personal mission to perfect the product and a series of fixes were deployed until the final release of the Prayer Room / Mesivta Derakia app was deployed on El Al aircraft on 5 Feb, 2023. At this point, the app started displaying accurate zmanim. Boris and the FlightPath3D team put a lot of effort into perfecting it into an easy-to-use app. To ease understanding of zmanim on flights that cross time zones, the app shows countdown times to the upcoming zmanim.
The El Al Zmanim app showing the default current aircraft location zmanim
For example, El Al flight LY 26 from New York to Israel departing at 9pm will show a countdown to chatzos/midnight, alos hashachar (two variants) and later zmanim (such as misheyakir, sunrise, etc.), displaying a countdown, with the number of hours and minutes to upcoming zmanim. Zmanim are calculated based on the plane’s current location, speed and the flight path. Since headwinds and tailwinds (as well as in-flight route changes) can significantly change the time that zmanim will be reached, the times to the upcoming zmanim are recalculated multiple times a minute. This significantly reduces the challenge to passengers, since precalculated zmanim do not come close to real time calculations on the flight. The app also shows a compass with the bearing to Yerushalayim / Jerusalem (map). The FAQ that is part of the zmanim app on the aircraft appears in a hyperlinked version at El Al In-Flight Zmanim FAQ on this site. The app defaults to the Aircraft location but can be changed to show zmanim for multiple international cities
The El Al zmanim app displaying zmanim for New York
, displayed in the time and time zone of those cities. The app works in both English and Hebrew, based on the language selected in the flight entertainment system. A thank you goes to R’ Chaim Keller of the indispensable Chai Tables project for allowing the development team access his flight path algorithms. The FAQ would not have been possible without help of translators and copy-editors.
The El Al Zmanim app in Hebrew
A special thanks to Effie Freiner from Lakewood for the Hebrew translation (the “Yeshivish” Hebrew posed its own set of challenges), and to my wife and Dovid Nachfolger for clarifying the language and grammar in the English FAQ.
I spent time with Rabbi Dovid Heber, Rabbi Dovid Braunfeld, Rabbi Yisroel Harfenes and Reb Solly Tropper reviewing the various complexities of calculating in-flight zmanim before the app left the βeta stage and went live.

Developing Software for Aircraft

Developing apps for use on an airliner has a series of challenges, in particular for in-flight entertainment (IFE) systems. It is a complex process that requires a deep understanding of the aviation industry and the systems onboard the aircraft.

First, the hardware hosting the apps goes through stringent safety certifications and has to pass a series of requirements. These include being isolated from any cabin and aircraft controls. The most they can do is access the flight management system (FMS) in read-only mode, with no ability to push data to the FMS. These certifications are done for each aircraft configuration and can take a year or more to complete.

Software and the associated apps also follow similar certification processes. The software must be designed to work seamlessly with any IFE systems already in place on the aircraft. Thus, it has to adapt to new and older hardware and operating systems and understand and adapt to idiosyncrasies in the data provided by the FMS. FlightPath3D is a leading provider of interactive mapping software for IFE systems. This type of software provides passengers with real-time information about their flight’s location, altitude, and speed, as well as other relevant data such as the estimated time of arrival and the distance to the destination. This made FlightPath3D a natural vendor for the zmanim work. FlightPath3D has a wealth of experience in developing high-quality software solutions that meet the needs of airlines and passengers and adapt to the particular hardware installed onboard.

לז״נ אבי מורי הרב יצחק אריה בן ר׳ ברוך הירשפלד ז״ל. נפ׳ י׳ אדר ב׳ תשפ״ב.
In memory of my father R’ Yitzchok Hershfeld (Montreal).

Vasikin is When?

The sundial on the Zoharei Chama Synagogue as it appears on a 2014 Israeli stamp.

The KosherJava site now has a new vasikin calendar generator tool. This allows vasikin minyanim to generate customized vasikin charts. Offsets for various pre-sunrise davening points can be set. There are separate weekday, Shabbos, Yom Tov and Rosh Hashana / Yom Kippur offsets for each davening point. The format of the charts is Excel, but it is optimized for printing eye pleasing charts.
I would like to thank Howard Reichman who requested a vasikin calendar for the Los Angeles LINK Kollel vasikin minyan that ended up with the development of this zmanim tool. Howard graciously funded the next 7 months of hosting for

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));


א׳ תשרי תשפ״ג - 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.

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/10th 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
Location7.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)
Lat: 31.7°
2 sec7 sec15 sec26 sec
Lat: 40.1°
2 sec7 sec20 sec38 sec
Lat: 45.5°
3 sec10 sec30 sec90 sec
Lat: 50.05°
3 sec13 sec93 secN/A
Lat: 51.5°
4 sec16 secN/AN/A
Lat: 58.68°
13 sec47 secN/AN/A
Lat: 61.2°
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.
    30 Min7.203°7.199°7.208°7.205°
    50 Min11.432°11.424°11.449°11.442°
    72 Min16.055°16.04°16.092°16.08°
    90 Min19.804°19.784°19.865°19.848°


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 Manet 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 20th back to March 16th (or from September 22nd to the 26th).

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 Manet in his Zmanei Halacha Lema’aseh (4th 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.