Tag: Zmanim

Inflight Zmanim Calculations – Why So Complex?

Airline ZmanimDetermining zmanim times while on an airline flight is rather complex compared to calculating it for a fixed location. Some of the complexity involves:

  • Where you are currently located
  • Your Speed
  • Direction of travel / flightpath

The above 3 variables impact the calculation of what the zmanim are in your current location and where you will likely be when various zmanim are met.

Surprisingly, the hardest part is figuring out your current location. The shortest point between 2 points on the globe is the great circle route. Though it is the shortest path, airliners rarely fly this way. To take advantage of prevailing winds such as the Gulf Stream, or to avoid bad weather, airlines often fly much longer routes and as a passenger you often do not know exactly where you are.
Yes, the airline shows you a nice location map, but getting your exact coordinates from the map is not something that they usually supply. From a practical perspective, many people on domestic and short international flights will manage to figure out davening times by themselves. As a general rule of thumb, it is time for Shacharis when the sun rises and time for Maariv when it gets dark. Please keep in mind that most poskim are of the opinion that we use zmanim at sea level elevation, or ground level, and not the 37,000 foot elevation of the flight. This elevation results in a difference of approximately 20 minutes in sunrise and sunset times. Not sure when Mincha time is? Wait until shortly before sunset. Just keep in mind that when flying due east (such as a flight from NY to Israel), you are flying in the opposite direction as the sun and the time for davening is compressed. While you may expect sof zman krias shema to be 1/4 of the way into the day, in this case the davening window is compressed into a much shorter time. The real complexity is in flights that cross the halachic dateline, polar flights and to a lesser degree, cross-Atlantic and Pacific flights. This article will not delve into the halacha of in-flight zmanim, but solely on the technical aspects of figuring out the zmanim times.

GPS

Using your phone’s GPS to identify your in-flight location, or even a standalone GPS device will usually not work once you are away from cell towers (where your GPS no longer has the assistance of A-GPS). GPS signals are very weak and your GPS receiver typically does not have an antenna strong enough to pick up the signals in an aluminum or even newer carbon fiber composite airplane like the Airbus A350 and Boeing 787. To receive a signal, an external GPS receiver is usually required and assuming that you can get a signal (it helps if the external receiver is placed by a window), we can proceed. Note that while you would expect that the CFRP body of a Boeing 787 would allow for a much stronger signal than aluminum airliners, the graphite (and probably other materials) in the 787 and A350, CFRP in conjunction with the electrochromic windows on the 787, completely block GPS signals. In addition, to protect from lightning strikes, the A350 has a metal mesh embedded in the CFRP that further reduces the signal penetrating into the aircraft body. It is this shielding as opposed to GPS jamming that blocks signals on El-Al (and other airlines) 787s and A350s. In my testing with an external GPS device designed for aviation such as the Dual XGPS 160, the composite A350 and 787 both do not allow enough GPS signal through for a GPS receiver to provide a location fix. It may be surprising that it is easier to receive the weak GPS signal in an aluminum fuselage than a composite one, but keep in mind that carbon fiber is an excellent electrical conductor. Carbon fiber was used as the filament in Thomas Edison’s early light bulbs and does not let RF signals through and effectively acts as a Faraday cage. If you are able to receive a GPS signal, you can accurately calculate zmanim for your current location using tools such as the KosherJava zmanim map. Just change the latitude and longitude to what you see in your GPS in the URL https://kosherjava.com/maps/zmanim3.html?lat=75.74&lng=-63.22&zoom=3. While not an ideal solution, it does work. The same works for the rare airlines whose maps do show accurate GPS coordinates. Please note that Wi-Fi based geolocation will not work on your flight (in my testing it gave the location of the service provider headquarters).

Precalculated Flight Paths

Another way to figure out where you are located when in the air is via a precalculated flight path. This allows programs such as the Chai Tables Chai Air Times program for Windows and Android to work. However, they just calculate a great circle route between the origination and destination locations, something that is not very accurate. Currently MyZmanim’s Inflight charts are the most practical. These charts calculate the average path of the 5 previous flights in an attempt to better estimate your flight path and provide precalculated charts based on the time you take off. Since it is just an estimate, the charts provide a relatively large window of time where zmanim may happen. This is painful and causes a lot of confusion and uncertainty, but is probably unavoidable. While this solution is currently the best that I am aware of, there are a number of issues with it. For one, much of the flight path over the oceans and Arctic that are provided by services such as FlightAware and others (that are used by MyZmanim) are just educated guesses for cross oceanic or Polar flights, since there are no ADS-B receivers in much of this area. As a matter of fact, this terrestrial ADS-B receiver-free area comprises 75% of the globe. Even if the previous flight paths were accurate, your current flight may be very different. Flights such as the Cathay Pacific flights from the NY area to Hong Kong fly either east or west depending on wind conditions. MyZmanim deals with this scenario by providing both east and west maps (based on the in-flight map you would use one or the other) and indicating the portion of a flight-path that is unknown, but this is a warning that does nothing to help you accurately calculate zmanim.

ADS-B Receivers

Every airliner broadcasts its position, heading, altitude and speed using ADS-B. A technical user can bring an ADS-B-receiver with him on the flight and use it to retrieve the current information on his flight. This would work even when there are no ground based ADS-B receivers. This is something costly and beyond the technical ability of the vast majority of flyers.

The future

Due to issues in tracking flights that came to light with the disappearance of Malaysia Airlines Flight 370, satellite based ADS-B tracking is rolling out and will be mandated. This will make it much easier for services such as MyZmanim to provide more accurate pre-flight estimates, since services such as Flight-Aware will be able to provide more exact historical flight paths. For users who do have in-flight Wi-Fi, services such as FlightAware will be able to provide almost real time location (note that many services have a 5 minute delay and are not really real-time), allowing future Wi-Fi connected zmanim apps to tap into this and provide accurate zmanim.

FAQ: Chatzos Hayom VS Chatzos Halayla (Solar Noon VS Astronomical Midnight)

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

Question:

Is there a difference in time between the zmanim of chatzos hayom and chatzos halayla (astronomical midnight and astronomical high noon / midday) besides the obvious 12 hour difference?

Answer:

I was recently asked by a developer why the KosherJava zmanim library does not have distinct calculations for chatzos halayla. The answer is that the zmanim API does indeed have the getSolarMidnight() calculation, but for the most part there is no real need for it. The time of chatzos halayla / midnight or chatzos hayom (solar transit / solar noon or midday) stays pretty constant from day to day. In the worst case scenario (on around December 22nd), the length of the solar day would increase by about 30.16 seconds from one day to the next. This does not change by location, but is the same anywhere in the world. This would mean that chatzos halayla could be a maximum of 15.08 seconds different than just using midday + 12 hours. This is something that should not really impact people. In addition, the developer in question does not even show seconds, making this a moot point. In short, chatzos on any given day should be considered accurate enough for both chatzos hayom and chatzos halayla of that day. It should be noted that the Mishnah Berurah quoting a number of achronim and the Shulchan Aruch Harav are of the opinion that chatzos halayla is exactly 12 hours after chatzos hayom. The Mishnah Berurah states in הלכות הנהגת אדם בבקר א׳ ט׳

וזמן חצות הוא תמיד באמצעות הלילה ממש בכל מקום ואפילו בלילות הארוכות או הקצרות והיא י״ב שעות אחר חצי היום …

and the Shulchan Aruch Harav in הלכות השכמת הבוקר א׳ ח׳ states that

וזמן חצות לילה הוא שוה בקיץ ובחורף לעולם י״ב שעות אחר חצי היום שהוא אמצע הלילה ממש …

Chatzos Halayla on the Seder Night

MatzosThe time of year that the zman of chatzos has the greatest impact is during the Pesach seder when people want to finish the afikoman before chatzos. During this time of the year the solar days are shrinking slightly from day to day, resulting in chatzos halayla being slightly earlier than chatzos hayom + 12 hours. The difference in the length of the solar day from solar noon on erev Pesach to solar noon on the first day of Pesach ranges from 11 to 18 seconds depending on the year. On the very late erev Pesach on April 24 that last occurred in 1929 and 1967 and will next occur in 2043 and 2062 there is an 11 second difference. On the extremely early erev Pesach of March 25 that occurred in 1899 and 2013 and will occur next in 2089 (see Rabbi Dovid Heber’s Why is This Pesach the Earliest Since 1899?) there is an 18 second difference. This 5.5 to 9 second difference in the time of chatzos hayom VS chatzos halayla on erev Pesach is something that has almost no real world impact. It is interesting to note that based on the fact that the average Jewish year is slightly longer than the average solar year, the early March 25 erev Pesach will never happen again after 2089.

Equation of Time (EoT)

You may have expected that the longest day of the year – the summer solstice (June 20 or 21 depending on the year) would be the day with the earliest sunrise / netz (or hanetz) and latest sunset / shkiah (and therefore the day with the latest start of Shabbos). However the earliest sunrise actually occurs on or about June 14 (at latitude 40° – it varies slightly based on latitude), a week before the longest day, and the latest sunset occurs on or about June 28, a week after the summer solstice. As mentioned above, the length of the day that we know to be exactly 24 hours on a clock is actually only an average over the year. The length of the day varies slightly from day to day. This length of day range is from a minimum of 23 hours, 59 minutes and 38.64 seconds around September 17 to a maximum of 24 hours and 30.16 seconds around December 22 vs the previous day. This accumulated length of the day difference is known as the equation of time. While the day starts shortening after the solstice, chatzos (and by extension the entire day) is moving slightly forward as the solar day (midday to midday) grows at this time of the year, resulting in the day ending later despite it being shorter.

Note: The rest of the article is somewhat technical and can be skipped if you have no interest in detailed explanations as to why days differ in length.

The cause of the change is due to the following two main factors. The very minor impact of nutations (such as the Chandler wobble), axial precession and other factors are too small to make a practical difference in the EoT calculations.

The tilt of the Earth’s Rotational Axis

The tilt of the Earth’s rotational axis (also known as the axial tilt or the obliquity of the ecliptic) as compared to the plane of its orbit around the sun is one factor that impacts the length of the solar day. To understand this, note that the earth rotates on it’s axis in 23 hours 56 minutes and 4.1 seconds in relation to the stars. This is called a sidereal day. The remaining 3 minutes and 55.9 seconds or about 0.98° of rotation must be made up every earth day. Due to the 23.44° axial tilt, this 3 minutes and 55.9 seconds is only an average.

The sun’s path through the sky during the March equinox. The equatorial grid is blue, the ecliptic grid is orange and the ecliptic (the sun’s apparent path) is yellow.
During the equinoxes the earth’s 23.44° tilt results in the sun having to travel a drop farther (1.09° for every 1° of eastward travel) to cover a line of longitude, since its path is angled and traveling a drop northwards or southwards on its path west. This results in the day being slightly shorter, since the sun only travels about 0.9° along the equator as opposed to the average of 0.98° per day.
The sun’s path through the sky during the December winter solstice. The equatorial grid is blue, the ecliptic grid is orange and the ecliptic (the sun’s apparent path) is yellow.
In the winter and summer the sun’s path is parallel to the equator and has a direct east/west path. In addition, since the longitude lines are closer together at 23.44° degrees from the equator the sun travels further moving 1.09° parallel to the equator for every 1° of eastward travel. This results in a slightly longer day. A technical and detailed explanation can be found in Mike G’s explanation of the subject at the astronomy section of StackExchange (where the above Stellarium generated images are from) and in Art Carlson’s equation of time explanation.

The elliptical orbit of the earth

The elliptical orbit of the earth (or the eccentricity of the Earth’s orbit) is the second factor that impacts the length of the day. The earth’s orbit around the sun is an ellipse and not a perfect circle. Following Kepler’s second law, the earth moves slightly faster in orbit when it is closer to the sun, and slower when it is farther away. During the perihelion (it ranges between January 2 and 6 depending on the year) when the earth is closest to the sun at 91,402,500 mi / 147,098,070 km distance, it travels at 30.287 km/s, while at the aphelion (between July 3 and 7) when it is 94,509,100 mi / 152,097,700 km away, it travels at 29.291 km/s. In addition, the angular velocity of the sun is faster (in relation to the stars) when it is closer to earth. Despite it being somewhat counter-intuitive, the sun is closer to earth in middle of the northern hemisphere’s winter than during the summer. This non-uniform orbital speed impacts the length of the solar day.

The Accumulated Difference

This difference between our standard clock time and the time that would be based on the exact position of the sun in the sky accumulates and is referred to as the equation of time (EoT). Equation in this case refers to equality and not a mathematical equation (though the calculations certainly involve mathematical equations), and adding or subtracting this time allows us to sync solar time and clock time (mean solar time / universal time).
Please see the references section below for links that cover the topic in detail.

Note: This article is explained using a heliocentric based model. I would appreciate if my readers who follow the geocentric model would be able to post a detailed explanation of this article based on that view.

Thank you.

References

I would like to thank my son Shai for the detailed work on the technical part of this article.

Baal Hatanya’s Zmanim Added to KosherJava Zmanim Library

Baal Hatanya Zmanim (Photo With Hourglass)
While most calendars list the גר״א Gra and בעל התניא Baal Hatanya zmanim as identical, things are not that simple. Both are based on a day being from sunrise to sunset, but recently some Chabad calendars started using slightly different calculations for the Baal Hatanya’s zmanim. It should be noted that these zmanim are not universally accepted in Chabad (see the Opposing View section below). According to the Baal Hatanya in the סדר הכנסת שבת Seder Hachnasas Shabbos,

Seder Hachnasas Shabbos -Shkiah Amitis

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

zmanim are calculated based on a 4 minute delay in shkiah. These 4 minutes are calculated as the sun’s position in degrees before sunrise and after sunset. While Chabad considers netz (also known as hanetz) as standard sunrise and shkiah as standard sunset, this is lechumra, and other zmanim are based on a slightly earlier sunrise and a slightly later sunset.

About 3 1/2 years ago, I posted information on calculating the Baal Hatanya’s Shkiah. That article was focused on a software developer’s perspective and explained how to use the existing API to calculate a fixed clock 4 minute zman that was not natively supported by the KosherJava zmanim library. Recently Yechiel Paricher contributed code to the KosherJava zmanim API/Library that added native support for various Baal Hatanya zmanim. This will enable users of the Zmanim library to easily include Baal Hatanya zmanim in their software.

According to the Baal Hatanya, shkiah amitis (true halachic sunset) is defined as:

כי אחר סילוק וביאת האור מראשי האילנות וגגים הגבוהים בכמו ד׳ חלקי ששיים משעה (שקורין מינוטין) אזי היא שקיעה האמיתית, שהוא סילוק וביאת האור מראשי ההרים הגבוהים שבארץ ישראל.

The time is calculated as the point at which the center of the sun’s disk is 1.583° below the horizon. Chabad applies the same degree based offset to netz amiti (true halachic sunrise). This degree based calculation can be found in Rabbi Shalom DovBer Levine’s commentary on The Baal Hatanya’s Seder Hachnasas Shabbos. From an elevation of 546 meters at the top of Har Hacarmel (based on the Gemara Shabbos 35a), the sun disappears at sunset when it is 1.583° (1° 35′) below the sea level horizon. There are other opinions that are not included in the code (but can easily be calculated using the API). One such example is a very similar (degree-wise) netz amiti from Rabbi Yosef Yitzchok Feigelstock. Rabbi Feigelstock calculates shkiah amitis as the degrees below the horizon 4 minutes after sunset in Yerushalaym (on the equinox). That degree based zman is listed in his letter to Rabbi Levine published in the back of the Seder Hachnasas Shabbos as 1.583°. The 1.583° is a typo (confirmed by Rabbi Feigelstock since it is identical to the 1° 35′ zman) and should be 1.683°. The calculations added to the KosherJava Zmanim library are used by most Chabad calendars that follow the Baal Hatanya’s Zmanim. See About Our Zmanim Calculations @ Chabad.org.

Zmanim based on shaos zmaniyos are based on a day between netz amiti and shkiah amitis calculated as 1.583° below the horizon. The various Baal Hatanya zmanim now part of the zmanim library include:

  • Alos 16.9° – based on the sun’s position below the horizon 72 minutes before netz amiti in Yerushayim around the equinox.
  • Sunrise or netz amiti – calculated as 1.583° below the horizon. This method is private and is only used as a base for other calculations.
  • Sof Zman Shma – calculated as 3 shaos zmaniyos (or a 1/4 of the day) after netz amiti.
  • Sof Zman Tfila – calculated as 4 shaos zmaniyos (or a 1/3 of the day) after netz amiti.
  • Sof Zman Achilas Chametz – calculated as 4 shaos zmaniyos (or a 1/3 of the day) after netz amiti.
  • Sof Zman Biur Chametz – calculated as 5 shaos zmaniyos after netz amiti.
  • Mincha Gedola – calculated as 6.5 shaos zmaniyos after netz amiti.
  • Mincha Gedola – Greater Than 30 – As above, but with a minimum 30 clock minutes after chatzos.
  • Mincha Ketana – calculated as 9.5 shaos zmaniyos after netz amiti.
  • Plag Hamincha – calculated as 10.75 shaos zmaniyos after netz amiti.
  • Sunset or shkiah amitis – calculated as 1.583° below the horizon. This method is private and is only used as a base for other calculations.
  • Tzais – calculated as the time when the sun is 6° below the western horizon. Note that as per Rabbi Yosef Yitzchok Feigelstock, for Motzai Shabbos, Motzai Yom Kippur and Motzai Yom Tov, the 8.5° time should be used. The time between 6° and 8.5° is part of tosfos Shabbos and tosfos Yom Kippur. Other zmanim such as zman krias shema can use the 6° zman. The 8.5° zman has always been part of the API, and sample code for calculating tzais 8.5° can be seen below.

These zmanim (not my implementation) that Chabad.org spent 2 years researching, have a haskama (endorsement) from Chabad Dayanim. Chabad.org zmanim do not provide seconds (appropriate due to expected refraction variances), but with the rounding rules provided by Rabbi Mordechai Sandhaus, the lead developer at Chabad.org, I was able to confirm that the Baal Hatanya zmanim generated by the KosherJava zmanim library match the Chabad.org times.

Please note that there are various Chabad shittos for netz, shkiah and tzais zmanim. The above are the commonly used ones. Other opinions on Baal Hatanya based zmanim that are less commonly used are not included in the API, but given the flexibility of the KosherJava Zmanim API they can easily be calculated.These include:

  • Netz Amiti 1.683° as calculated by Rabbi Feigelstock and mentioned above (only used for calculating other zmanim).
  • Shkiah Amitis 1.683° as calculated by Rabbi Feigelstock and mentioned above (only used for calculating other zmanim).
  • Tzais 5.833° as calculated by Rabbi Shalom DovBer Levine lekula for derabanans.
  • Tzais 6.3° as calculated by Rabbi Avrohom Altein, Chabad of Winnipeg, Manitoba, Canada.
  • Tzais 6.833° as calculated by Rabbi Shalom DovBer Levine lechumra for deoraysas.
  • Tzais 8.5° as commonly used by Chabad lechumra and mentioned above.

Code samples for these zmanim can be seen below.

Opposing Views

The relatively new calculations of zmanim based on netz amiti and shkiah amitis are not universally accepted in Chabad. Rabbi Avrohom Altein, the Rov of Chabad of Winnipeg, Manitoba, mentioned in a correspondence, that it is difficult to accept these new zmanim calculations as is.

The Alter Rebbe only speaks explicitly of shkiya amitis in regards to the beginning of Shabbos. We can draw comparisons to other areas of halacha but those comparisons needs to be carefully evaluated.
I believe that the Alter Rebbe does not calculate shaos zmaniyos based on netz & shkiya amitis, but rather on the standard netz & shkiya. There are several strong proofs to this. In earlier years, all of Chabad calculated shaos zmaniyos for laws of chometz, reading Shema etc., on the basis of standard sunrise and sunset and I believe that’s how the older Colel Chabad Luchos did the calculation. In recent years, this has changed in the Colel Chabad Luchos and chabad.org based on the opinion of Rabbi SDB Levin and Rabbi Feigeslstock — but there are Chabad rabbis that do not agree with their interpretation.

Code Samples

For developers, here is sample code that calculates the new zmanim. This should allow many zmanim apps to add Baal Hatanya zmanim with very little effort.

String locationName = "770 Eastern Parkway";
double latitude = 40.669;
double longitude = -73.943;
double elevation = 30;
TimeZone timeZone = TimeZone.getTimeZone("America/New_York");
GeoLocation location = new GeoLocation(locationName, latitude, longitude, elevation, timeZone);
ComplexZmanimCalendar czc = new ComplexZmanimCalendar(location);
czc.getCalendar().set(1994, Calendar.JUNE, 12);
System.out.println("Alos: " + czc.getAlosBaalHatanya()); //16.9 degrees
System.out.println("Sunrise: " + czc.getSunrise()); //standard sunrise
System.out.println("Sof Zman Shma: " + czc.getSofZmanShmaBaalHatanya());
System.out.println("Sof Zman Tfila: " + czc.getSofZmanTfilaBaalHatanya());
System.out.println("Sof Zman Achilas Chametz: " + czc.getSofZmanAchilasChametzBaalHatanya()); //only use on Erev Pesach
System.out.println("Sof Zman Biur Chametz: " + czc.getSofZmanBiurChametzBaalHatanya()); //only use on Erev Pesach
System.out.println("Mincha Gedola: " + czc.getMinchaGedolaBaalHatanya());
System.out.println("Mincha Gedola Min 30: " + czc.getMinchaGedolaBaalHatanyaGreaterThan30());
System.out.println("Mincha Ketana: " + czc.getMinchaKetanaBaalHatanya());
System.out.println("Plag Hamincha: " + czc.getPlagHaminchaBaalHatanya());
System.out.println("Sunset: " + czc.getSunset()); //standard sunset
System.out.println("Tzais Baal Hatanya: " + czc.getTzaisBaalHatanya()); //6° degrees
System.out.println("Tzais 8.5°: " + czc.getTzaisGeonim8Point5Degrees()); //8.5° degrees lechumra commonly used by Chabad
System.out.println("Shaah Zmanis Baal Hatanya: " + czc.getShaahZmanisBaalHatanya());

Calculating other Baal Hatanya based zmanim not included in the library are very simple. Here are a few examples

System.out.println("Netz Amiti 1.683°: " + czc.getSunriseOffsetByDegrees(90 + 1.683)); //Rabbi Feigelstock netz amiti (only used for calculating other zmanim)
System.out.println("Shkiah Amitis 1.683°: " + czc.getSunsetOffsetByDegrees(90 + 1.683)); //Rabbi Feigelstock shkiah amitis (only used for calculating other zmanim)
System.out.println("Tzais 5.833°: " + czc.getSunsetOffsetByDegrees(90 + 5.833)); //Rabbi Levine lekula for derabanans
System.out.println("Tzais 6.3°: " + czc.getSunsetOffsetByDegrees(90 + 6.3)); //Rabbi Avrohom Altein
System.out.println("Tzais 6.833°: " + czc.getSunsetOffsetByDegrees(90 + 6.833)); //Rabbi Levine lechumra for deoraysas

I would like to thank Rabbi Yosef Yitzchok Feigelstock, the Rov of Chabad in Buenos Aires, Rabbi Avrohom Altein, the Rov of Chabad in Winnipeg and Rabbi Mordechai Sandhaus, the lead developer at Chabad.org for reviewing this post.

FAQ: Zmanim and Leap Seconds

Leap Second

Questions:

Answers:

  • Yes
  • Yes, but infinitesimally

Before delving into the answer, I would like to note that zmanim accuracy / precision down to the second that are supported by the API are really nonsense, because variations in refraction make this accuracy pointless. The second (or millisecond) zmanim accuracy / precision subject will hopefully have its own article in the future.
Since 1972, 27 leap seconds have been added to UTC time VS International Atomic Time (TAI). This is in addition to the initial 10 seconds added in 1972 to reflect pre-1972 corrections. The reason for adding leap seconds is to correct our clocks for incorrect original estimates of the speed of earth’s rotation. Assuming that you keep your clock time correct (and add the leap seconds), no change in any zmanim calculations by either the KosherJava zmanim library, or any other zmanim programs or APIs are needed. However, if you have a very accurate clock, and did not change it since 1972, your zmanim calculations will be off by 37 seconds. This is not something any zmanim APIs, apps or programs should have to deal with. Had we added any corrections for leap seconds, your zmanim calculations would be inaccurate.
As far as the Tōhoku earthquake in Japan, this is really the same question as the first question. Yes, that earthquake slowed down earth’s rotation by 1.8 microseconds or 1.8 millionth of a second (meaningless for zmanim). This as well as the impact of other earthquakes that impact earth’s rotation are factored into the leap second calculations that “correct” the time of our clocks and ensure that your zmanim are correct.

Technical Details

The leap second corrections address incorrect clock time that result from a slower earth rotation than expected. To get a drop more technical (thank you Pinny Markowitz), when the rate or the angle of rotation changes (due to earthquakes or other natural or man-made changes such as building of the Three Gorges Dam), the changes are minuscule. These small changes as well as the original incorrect calculation of the length of the day add up over time. On occasion (about every 2 years) the accumulated difference is significant enough to warrant introducing (or theoretically removing, something that has yet to happen) a leap second to reconcile our clocks with the natural one. On any given day, UTC time always considers 86,400 (60 * 60 * 24) seconds as a day. On the day with a leap second, UTC time still considers the day as having only 86,400 seconds, but a second is added to account for each of the seconds over a year or more being a drop too short. There are various ways of making system clocks conform with the UTC standard, but the net effect is always the same, an extra second is added. UTC doesn’t view a second the same way that the atomic clocks (International Atomic Time) do. UTC views a second as 1/86,400 of a relative day (that is actually 86,400.002 seconds long on average), while, atomic clocks count a day as 86,400 fixed length seconds. Fortunately, the approach of adding leap seconds is exactly what we need when calculating zmanim. By ignoring leap second events in zmanim code, and instead focusing on the measurements of a relative day, we can yield calculations that will be correct in the context of a relative day (assuming that you properly adjust your clock).

ZIP Codes and Zmanim – Use With Care

99557 ZIP code area (the largest in the USA)
99557 ZIP code area (the largest in the USA)
There are many zmanim services and apps that use ZIP codes as a location finder for calculating zmanim. While very convenient, there is a potential pitfall in using ZIP codes for geolocation. In general, ZIP code geolocation services will provide the center of the ZIP code and zmanim apps calculate zmanim for that location. The issue arises with large ZIP code areas mostly found in rural areas. Take the following two extreme cases that have very large ZIP code areas. ZIP code 89049 for rural Tonopah, NV, is 195 km (121 mi) from east to west. The eastern boundary of this non-contiguous ZIP code has a longitude of -115.417°, while the western boundary is -117.625°. This means that there are 2.2° of longitude between the eastern and western borders of this ZIP code. The earth rotates 1 degree every 4 minutes, so zmanim at the eastern and western edges of this ZIP code are approximately 8.8 minutes apart. Using the typical center of the ZIP based calculations would mean that zmanim would be about 4.4 minutes different at the edges compared to the center. Moving to something a bit more extreme, is the case of ZIP code 99557 of Aniak, Alaska and its surrounding area. This ZIP code is 415 km (258 mi) from east to west. The longitude of the eastern edge of the ZIP code is -153.032°, and the western edge is -160.783°. Being farther north and therefore having shorter distances between degrees of longitude, this ZIP code stretches across 7.7° of longitude. The zmanim difference from the center to the edges of this ZIP code is 15 and a half minutes (31 minutes across the ZIP). While it is indeed rare to have such large distances, there are 193 US ZIP codes that are over 1° of longitude wide, meaning that the zmanim difference for these ZIP codes are at a minimum 4 minutes apart, or 2 minutes off from the center. There are 1,463 or 4.4% of all ZIP codes with 0.5° or greater distance between east and west (a minimum of a 2 minute zmanim difference between the east and west zide of the ZIP code). zmanim software developers should be aware of this, and take care to alert users of possible inaccuracies when using large ZIP code areas, or require addresses or more specific location information for large zip codes.
Let’s contrast the above with Lakewood, NJ. With 0.107° of longitude from east to west, zmanim are 24 seconds later on the west side (the intersection of New Central Ave & N Hope Chapel Rd) than the east side (Shinn Cranes, 1600 Ocean Ave). New York City is larger, and from the western edge of Staten Island to the edge of Glen Oaks, the eastern edge of Queens there is a 2 minute and 11 second difference in zmanim.
See the Calculation of Zmanim VS Other Sites post for additional related material.
I thank Avraham David Gelbfish for generating the ZIP code longitude range for all 33,093 ZIP codes from the US Census Bureau ZIP code shape files.