Times for Sof Zman Shma not like Itim Levina

[YizYah]

I contacted the creator of the calendar Itim Levina, which is highly accepted in most of Israel.

Based on the precise latitude, longitude and elevation that he claims to use for Beitar Ilit, I generated this gloc:

  const latitude = 31.693;
  const longitude = 35.108;
  const elevation = 659.7;
  const tzid = "Israel";
  const gloc = new GeoLocation("Betar", latitude, longitude, elevation, tzid);

The times I get from hebcal are consistent with the calendar within seconds for most things. But, when it comes to sof zman shma, they are off by enough time that people would object to the error. If I do this:

  const zmanim = new Zmanim(gloc, new Date(2024, 3, 23), false);

  console.log( `sof zman shma Magen Avraham = ${zmanim.sofZmanShmaMGA()}`);
  console.log( `sof zman shma = ${zmanim.sofZmanShma()}`);

I get this:

    sof zman shma Magen Avraham = Tue Apr 23 2024 08:43:57 GMT+0300 (Eastern European Summer Time)
    sof zman shma = Tue Apr 23 2024 09:17:57 GMT+0300 (Eastern European Summer Time)

But Itim Levina gives 8:32- and 9:20+ for those.

I've tried coming up with calculations for both.

GRA

I tried the formula given in your explanation for sofZmanShma(): /** Latest Shema (Gra); Sunrise plus 3 halachic hours, according to the Gra */

function sofKriasShema(zmanim: Zmanim): Date {
  const netz = zmanim.neitzHaChama();
  const shkeya = zmanim.shkiah();

  // length of a halachic hour in milliseconds
  const halachicHour = (shkeya.getTime() - netz.getTime()) / 12;

  // 3 halachic hours after netz
  return new Date(netz.getTime() + 3 * halachicHour);
}

I ended up getting Tue Apr 23 2024 09:19:57 GMT+0300 (Eastern European Summer Time), which is closer. I'm not sure why my calculation is different than yours.

MGA

The calendar claims that it uses 90 minutes rather than 72. Here's my calculation:

function sofKriasShemaLeMGA(zmanim: Zmanim): Date {
  const dawn = zmanim.timeAtAngle(20, true) // 90 minutes before sunrise
  const nightfall =  zmanim.tzeit(20) // 90 minutes after sunset

  // length of a halachic hour in milliseconds
  const halachicHourMGA = (nightfall.getTime() - dawn.getTime()) / 12;

  // 3 halachic hours after amud haShachar
  return new Date(dawn.getTime() + 3 * halachicHourMGA);
}

console.log(`zmanKreasShmaMGA = ${sofKriasShemaLeMGA(zmanim)}`)
  // zmanKreasShmaMGA = Tue Apr 23 2024 08:31:14 GMT+0300 (Eastern European Summer Time)

The small discrepancy with the calendar (8:32-) may be caused by zmanim.timeAtAngle(20, true) returning Tue Apr 23 2024 04:24:16 GMT+0300 (Eastern European Summer Time) rather than 4:24- as reported by the calendar.

But I wonder whether you could make a sofKriasShemaMGA90 on Zmanim to calculate this opinion.

[mjradwin]

Hi, thanks for your message, and our apologies for the delay in getting back to you.

We have investigated the GRA difference, and have identified a bug in our implementation. The sofZmanShma() was improperly ignoring the useElevation field that is specified in the Zmanim constructor. In your example, you have an elevation of 659.7 meters above sea-level, but you pass false in the constructor, which means that you are instructing the API to ignore elevation for most calculations, including the GRA calculation of sof zman shma.

In @hebcal/core version 5.3.7 this has been fixed and correctly return Tue Apr 23 2024 09:19:58 (differing by one second from your implementation).

Regarding the MGA calculation using 90 minutes, to be consistent with KosherJava (from which Hebcal's Zmanim are derived), we have added a new function sofZmanShmaMGA19Point8 which uses 19.8 degrees for 90 minutes (not 20 degress) and returns 04/23/2024, 08:31:46 which is very close to the 8:32 that Itim Levina publishes.

[YizYah]

Thanks @mjradwin, amazing!

But since you raise the point, elevation does not seem to be affecting sofZmanShmaMGA19Point8. For instnace,

  const date = new Date("2024-05-18T07:49:29.546Z")

  const latitude = 31.693;
  const longitude = 35.108;
  const elevation = 659.7;
  const tzid = "Israel";
  const gloc = new GeoLocation("Betar", latitude, longitude, elevation, tzid);

  const zmanimNoElevation = new Zmanim(gloc, date, false);
  const zmanimElevation = new Zmanim(gloc, date, true);

In the debugger:

> zmanimElevation.sofZmanShmaMGA19Point8()
Fri May 17 2024 08:16:38 GMT+0300 (Eastern European Summer Time)
> zmanimNoElevation.sofZmanShmaMGA19Point8()
Fri May 17 2024 08:16:38 GMT+0300 (Eastern European Summer Time)

Another unrelated point which confuses me a lot is that the published times in the Itim Levina calendar seem to be the same as the ones without elevation. For instance, on Friday May 17, 2024, the calendar sais that Netz is 5:41:45. That seems to sync with the result of not using elevation:

> zmanimElevation.neitzHaChama()
Fri May 17 2024 05:37:11 GMT+0300 (Eastern European Summer Time)
> zmanimNoElevation.neitzHaChama()
Fri May 17 2024 05:41:26 GMT+0300 (Eastern European Summer Time)

[mjradwin]

There are some zmanim such as degree-based zmanim that are driven by the amount of light in the sky and are not impacted by elevation. These zmanim intentionally do not support elevation adjustment. sofZmanShmaMGA19Point8 is one such calculation that utilizes the sun degrees below the horizon, so elevation is not included.

Regarding whether Itim Levina uses elevation for their calculations or not: we don't know. You mentioned earlier that you had contacted the creator of their calendar, so perhaps you could ask them.

For what it's worth, very few software implementations of solar calculations support any elevation adjustment for sunrise/sunset. Most of the libraries that are available for Java, Javascript, Golang, C, C++, PHP, Swift, etc support only latitude and longitude and do not accept an elevation parameter.

We added elevation support to the Hebcal Javascript implementation in December 2023, but other versions of Hebcal, such as the original C implementation and the current Golang implementation do not support elevation adjustment.

[YizYah]

Amazing. Your contributions are stunning.

If I could ask @mjradwin, could one claim that the use of elevation would give more accurate times (that is, people would if their implementations supported it, but it's technically difficult), or is it just a different shita?

In practice, people here seem to hold by Itim Levina because it is established, and does have approbations. If minyan times differ from those based on Itim Levina, people will complain. So even if it's less accurate, it's accepted.

That said, he even calculates Netz HaNira and appears to be very meticulous and sophisticated. So I imagine he could use elevation if he wanted to.

[mjradwin]

I believe (based on what we've learned from the folks at KosherJava) that elevation indeed improves accuracy of sunrise and sunset times, any times that are a fixed number of minutes before or after those events (e.g. candle-lighting time, which is usually 18 minutes before sunset), or times that use sunrise/sunset directly in calculations (for example the GRA versions of sofZmanShma and sofZmanTfilla).

As mentioned earlier, other degree-based zmanim are estimating the amount of light in the sky, and elevation does not affect those calculations.

I'm definitely not an expert in halacha and my ability to read Hebrew is pretty limited. Although I'm very interested in the calendar and holidays and zmanim, I've been deferential to those who are way more educated than I am (most frequently depending on the KosherJava folks, because they've done the research).

https://kosherjava.com/2010/03/07/faq-how-much-earlier-is-sunrise-on-mount-everest-due-to-elevation/

https://kosherjava.com/2022/01/12/equinox-vs-equilux-zmanim-calculations/