Upcoming Zmanim in El Al’s Latest Zmanim App. Note the latitude and longitude on the display as well as the version number.While there have been many technical updates to El Al’s in-flight zmanim app since it rolled out, none included changes to the visual user interface. In February, El Al rolled out a long awaited update by FlightPath3D to the user interface based on feedback received since the initial system was rolled out. The new UI has many enhancements including:
Displaying the latitude and longitude on the main screen to allow people to more easily validate the accuracy of zmanim calculations and simplify bug reporting. This feature involved a security review by El Al. To enhance reporting even further, the app version is displayed on the main screen. I am not aware of any software that shows the version on the main app screen, but we are doing what we can to help resolve any potential issues, and knowing the version number can help. Since feedback is often in the form of a picture of the screen, displaying the aircraft location and version number on the screen simplifies debugging issues.
A UI toggle to show a more extensive list of zmanim (not just a few past and upcoming ones).
Avoid showing the zmanim screen before takeoff (projections on the ground are too inaccurate, since the system has no idea when it will take off). Even showing zmanim for specific cities prior to takeoff was shelved in a UX review since it would likely confuse users who would think that it reflected the flight zmanim. The icon for displaying zmanim shows up as soon as the flight is underway.
Minor FAQ changes, including the addition of QR codes to simplify contacting us to report issues. Thank you YCS for the suggestion.
The Halachic Datelines (the Chazon Ish and Rav Yechiel Michel Tucazinsky) were added to the flight map. Note that graira / גרירה is used in the Chazon Ish (west) date line, but not Rav Tucazinsky’s (east) date line, since he was seemingly מסופק / unsure about concept. This change was a mapping update, and not a zmanim app update.
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 leftBoris 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 citiesThe 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).
לז״נ חמי ר׳ שרגא פייבל בן ר׳ שלמה יהודה מילר ז״ל. נפ׳ ט״ו אייר תשפ״ג. In memory of my father-in-law R’ Feivel Muller (Brooklyn / Lakewood).
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.
Converting from one number system to another can be tricky. What time would 6:19 am/pm on this decimal based analog clock be on a regular duodecimal (12 based) clock? See the end of the article for the answer.
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 BMGbeis 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 🙂.
99557 ZIP code area (the largest in the USA)As mentioned in the ZIP Codes and Zmanim – Use With Care article, using ZIP codes to geolocate your position for zmanim can be problematic when the zip code is large. With large zip codes, zmanim on the west side of the zip code can be quite a bit later than zmanim on the east side of the zip. Recently, Lazer Guttman created an SMS based zmanim service at (914) 409-9394 that provides a warning when zmanim are requested for large zip codes. This approach is probably the best that can be done. I would recommend that any zmanim service that is zip code based (and does not have a map to allow zeroing in to a precise location), use this data to provide a warning whenever the zip codes is wider than 0.5° of longitude. A degree of longitude spans 4 minutes (regardless of the latitude), so half of a zip code with half of a degree would span 2 minutes (one minute east or west of the center). It should be noted that Canadian postal codes are much smaller than zip codes (usually covering one side of a city block), and most likely do not face the same issue. A spreadsheet listing all zip codes with the maximum longitude and latitude distances (in degrees), was generated by Avraham David Gelbfish from OpenDataDE that is based on US Census data. His Python source code is below.
import json
import csv
jsonfile = open("tl_2019_us_zcta510/out2.geojson")
zipcodes = json.load(jsonfile)
def getop(geolist, operation, longitude = None, latitude = None):
if isinstance(geolist[0], list):
answers = [getop(geo, operation) for geo in geolist]
for answer in answers:
lat, lng = answer
if latitude is None:
latitude = lat
if longitude is None:
longitude = lng
latitude = operation(latitude, lat)
longitude = operation(longitude, lng)
return latitude, longitude
else:
return geolist
with open("out2.csv", "w") as csvfile:
zwriter = csv.writer(csvfile)
zwriter.writerow(["Zip", "Latitude max distance", "Longitude max distance"])
for zipcode in zipcodes["features"]:
zip = zipcode["properties"]["ZCTA5CE10"]
geometry = zipcode["geometry"]["coordinates"]
maxlat, maxlng = getop(geometry, lambda x, y: x if x > y else y)
minlat, minlng = getop(geometry, lambda x, y: x if x < y else y)
dlat = abs(maxlat - minlat)
dlng = abs(maxlng - minlng)
zwriter.writerow([zip, dlat, dlng])
While overly broad ZIP code based zmanim geolocation 
