Ofek Yerushalayim #354
Comments
|
Thanks for your feedback. Can you share a bit more detail about where the zmanim calculations diverge, and by how many minutes? Some concrete examples would be extremely useful. I don't live in Jerusalem, so perhaps you could post a photo of your favorite printed luach? As you already know, all zmanim are approximated from a location (latitude, longitude) and day of year. The algorithm used by Differences of 1-2 minutes between Hebcal and other sources publishing candle lighting times or sunset times are expected. Remember that candle lighting times can only be approximated based on location. Here are a few common reasons why you may see differences in candle lighting times: https://www.hebcal.com/home/94/how-accurate-are-candle-lighting-times The NOAA algorithm, as implemented, utilizes only latitude, longitude, and day of year. It does not utilize elevation. Even if the algorithm did use elevation, including Jerusalem's elevation into the formula would change the calculations by less than one minute. |
|
Sure thing. Here's some brief halachik background to whet the appetite. So, taking last week as an example, here are lighting times in jerusalem (40m)
Looking here things seem more or less on target. I'll post later with some times which seemed much more extremely divergent. Thanks :) |
|
Thanks. The 5-minute delta is difficult to explain. Sunset in Tel Aviv is only a minute after sunset in Jerusalem, so this isn't a latitude/longitude issue or an elevation issue. Could your luach be using a different formula for candle lighting time, for example 35 minutes before sundown? Or solar elevation of some number of degrees (instead of minutes before sundown)? I am not surprised by the 1-minute delta between Hebcal and Chabad. |
|
Tzeit is even more problematic. Depending on the angle i might be off by 15 minutes on either side, and that's worrisome wrt havdalah |
|
We give many options for Tzeit because there are many traditions. Some use fixed minutes past sundown (most common are 42 min for three medium-sized stars, 50 min for three small stars, 72 min for Rabbeinu Tam). Some use degrees below horizon (most commonly 8.5 degrees for three small stars, occasionally 7.0833 degrees for three medium-sized stars). https://github.com/hebcal/hebcal-es6/blob/main/README.md#HebrewCalendar.calendar
You can probably get the tzeit times to line up within 1-2 minutes if you learn what formula your favorite luach uses. |
|
clearly i have some homework to do. thanks. With your permission i'd like to keep this issue open until I can write up my findings a question: why are there separate parameters for tzeit and for havdallah? When would I want to compute tzeit by degrees, but havdallah by minutes? |
|
The API will throw an exception if you specify both The HebrewCalendar.calendar function is very convenient, but if you want more fine-grained control, consider using the Zmanim API directly. |
const {Zmanim} = require('@hebcal/core');
const latitude = 41.822232;
const longitude = -71.448292;
const friday = new Date(2023, 8, 8);
const zmanim = new Zmanim(friday, latitude, longitude);
const candleLighting = zmanim.sunsetOffset(-18, true);
const timeStr = Zmanim.formatISOWithTimeZone('America/New_York', candleLighting);
console.log(timeStr); |
|
So here are candle and havdalah times for some parshiot from the 'לוח דינים ומנהגים לשנת תשפ״ד'. Most of the printed luchot in jerusalem accord with these times give-or-take a minute or two.
And here are times derived from Hebcal with "Jerusalem" set as the city and an
Code for hebcal tableimport { HebrewCalendar, Location, HDate } from '@hebcal/core';
const times = [
'2023-10-13',
'2023-10-20',
'2023-10-27',
'2023-11-03',
'2023-11-10',
].map(iso => {
const start = new Date(iso);
const end = new HDate(start).add(1);
const location = Location.lookup('Jerusalem');
const [
{memo: parsha, eventTimeStr: candles},
,
{eventTimeStr: havdalah}
] = HebrewCalendar.calendar({
location,
candlelighting: true,
candleLightingMins: 40,
havdalahDeg: 8.5,
sedrot: true,
start,
end,
});
return { parsha, candles, havdalah }
})
console.log(`
| Parshah | Candles | Havdalah |
| ------- | ------- | -------- |${times.map(({ parsha, candles, havdalah }) => `
| ${parsha.replace('Parashat ', '')} | ${candles} | ${havdalah} |`).join('')}
`)As you can see, I'm able to align havdalah times with an artificially inflated |
|
Thanks for the comments and for sharing your code. Why do you say 8.5 degrees is an artificially inflated Havdalah angle? This is the default angle, which is used on many calendars for 3 small stars. Because it's the default, note that if you comment-out Second, for Friday night candle-lighting times, are you sure that your luach doesn't use 35 minutes before sunset? Have you checked any sources for Jerusalem sunset? According to this source https://www.timeanddate.com/sun/israel/jerusalem here are the sunset times for the dates you mention, and here are the times if you specify candle-lighting 35 minutes before sunset, or 40 minutes before sunset:
You'll note that the Hebcal sunset and 40-minutes before sunset candle-lighting times align 100% with this source. In other words, try changing your code as follows, and you will be pleased to discover that the times generated by const events = HebrewCalendar.calendar({
location,
noHolidays: true, // don't include holidays
candlelighting: true,
candleLightingMins: 35, // not 40
// havdalahDeg: 8.5, // 8.5 is the default
sedrot: true,
start: start,
end: end,
});As explained earlier, taking the elevation of Jerusalem into account changes the sunset calculation by less than one minute, and as such, it's not something that we will plan to include. |
|
If I go this way, members of my synagogue who are arithmetically inclined will notice two things
I don't think "we can just offset candle times and no one will notice" is a satisfactory answer to the fact that hebcal's fundamental zmanim (read: shkiya) do not accord with the accepted times in Jerusalem. זכור את רבני צפת שרצו להקים מחדש את הסמיכה בצדק ומתוך אהבת השם גמורה. היו להם כל הסיבות והסברות. היו נכונים וצודקים לגמרי, אבל לא התיעצו ולא המליכו בחכמי ירושלים, וכל עירם נחרב ונעשה שממה ברעש אדירה עד לחורבן שלמה. I will endeavour to provide a comprehensive comparison between hebcal and the detailed printer luhot. I understand the desire to provide a singular general codepath, but Yerushalayim is not a typical city. ואם תסכים להודות ללוח המקובל אצלינו בירושלים גם אם זה מצריך שינויים מיוחדים וכללים שונים לגבי עיר קודשינו ומקום מקדשינו מהרה יבנה, אז השם יברך אותך בכל הברכות הכתובות בתורת משה רבינו ויצליח דרכיך בכל אשר תלך, וראה בנים לבניך ויהיו נכסיך קרובים לעיר, תשיש ותשמח כל הימים באושר וכבוד Please consider the kavod of Yerushalayim, מקום שממנו תצא תורה ודבר השם, and endeavour to make the necessary exceptions in hebcal's codepaths such that hebcal's results for Jerusalem accord by default and without additional configuration with the minhag hamakom. I'm am willing and available to contribute in any way I can to making this so. |
|
It may help to illustrate the problem, so I prepared this demo |
If, however, you can provide me with a significant community in Jerusalem which relies on your times as a matter of halakha (rather than engineering) then I will be happy to retract my position and seek solutions elsewhere |
|
Let's start with location. When your code does const location = new Location(31.7759751, 35.2143054, true, 'Asia/Jerusalem', 'Jerusalem Great Synagogue', 'IL');Specifying a different latitude and longitude will indeed change the calculation, although likely by only a small number of seconds. Next, let's take a look at sunset. If your published shkiya times do not accord with the printed shkiya times, I would encourage you to start your investigations there. By shkiya, I am referring to the astronomical definition of sunset, which is defined as:
For a consistent latitude and longitude, you will find that any nearly any sunset algorithm, including Hebcal's, will generate consistent times within 1 minute according to that definition of sunset. The two most common algorithms are those published by NOAA (what Hebcal uses) and the USNO (generally considered to be less accurate). Either way, those calculations won't change by more than 1 minute, even when taking the elevation (estimated 786 meters above sea level) into account. If you find, however, that the printed source uses a different definition of sunset (for example, do they define sunset, for some reason, as when the sun is at angle 0.0° instead of -0.833° ?) then you really should start there. Next, you should determine how your printed source determines the minhag for candle-lighting time in Jerusalem. Do they really define it as 40 minutes before sunset, as is the usual custom in Jerusalem? Or, do they define it as solar depression by some number of degrees? We are very transparent with how the Hebcal algorithm works. I hope that your printed sources can also be as transparent, as this will help you to get to the answer for why you are seeing different calculations. |
|
Thank you for engaging. Again, I'm not saying your times are wrong or inaccurate, or that they can't be relied upon ח``ו. Nor am I claiming that you aren't transparent about your shittot. I applaud your correct and highly beneficial decision to release these libraries. I'm saying that your times don't accord with the accepted minhag in Jerusalem. Here's a table I prepared to illustrate the problem: https://bennypowers.github.io/shul-tools/zmanim/yerushalayim.html In this table, I've calculated shkiah and neitz times for 5 locations (lat/long) in jerusalem:
I then compared the results for shkiah from Hebcal at those 5 locations with the printed times from the לוח עיתים לבינה (by far, the most popular and comprehensive) and the לוח דינים ומנהגים published by Hechal Shlomo for the following dates from last year:
Itim Lebinah publishes a comprehensive kuntress outlining their approach. Shkiya Times
I sincerely hope it can be demonstrated that I made a mistake in my calculations here, but it does seem to me that Hebcal's times consistently diverge by several minutes from the accepted minhagim in Jerusalem. So what I'm asking for here isn't that you change your whole shittah or anything, what I'm asking is that for simple cases, you make an exception for the |
|
Thanks for your perseverance on this. Looking at the table you prepared, it would appear that the root cause of the problem is a different definition of skiyah. I'm glad that you were able to make this discovery. Since all calculations are derived from sunrise and sunset times, knowing that skiyah is the root cause of the discrepancy helps to get one step closer to the solution. The sunset discrepancy seems unlikely to be caused by a different latitude/longitude definitions, as evidenced by your experiments with different locations within Jerusalem generating a difference less than one minute. It could be caused by a different definition of sunset. Regrettably, my Hebrew comprehension is very poor, so I am unable to understand the Itim Lebinah document you posted. Or, as you suggested earlier, it could be caused by an elevation calculation difference. One excellent open source API, the ZmanimCalendar from KosherJava, has a long discussion about elevation. In the meantime, you might consider KosherJava's ZmanimCalendar, or a paid API such as the MyZmanim API; their developers may be able to offer you better support. If you are able to determine the root cause of the discrepancies between the published times, and have a suggested fix, we would be happy to receive a pull request. We're so sorry we can't help further with this issue. |
|
We wanted to let you know that we have done a bit of research on this. In fact, as you originally suggested, this may appear to be an elevation calculation difference. The ZmanimCalendar from KosherJava that we mentioned earlier supports elevation and calculates a 3-5 minute different for Jerusalem, depending on whether you utilize their sea-level sunset (e.g. 0 elevation) or sunset-with-elevation function. No fix expected anytime soon. The NOAA solar position calculator we use in JavaScript doesn't support elevation. We'll either have to find a suitable JavaScript package or port the elevation-aware code from Java to JavaScript. There is a KosherZmanim port but it uses an outdated and gigantic Luxon date-time library so it can't be incorporated into |
|
might be worth porting over the relevant code, but replacing the luxon stuff with a Temporal polyfill |
|
Thanks for the suggestion! We've taken a subset of the KosherZmanim code and have replaced luxon with Temporal polyfill. Can you take a look at the const {GeoLocation, Zmanim} = require('@hebcal/core');
const latitude = 41.822232;
const longitude = -71.448292;
const tzid = 'America/New_York';
const friday = new Date(2023, 8, 8);
const gloc = new GeoLocation(null, latitude, longitude, 0, tzid);
const zmanim = new Zmanim(gloc, friday);
const candleLighting = zmanim.sunsetOffset(-18, true);
const timeStr = Zmanim.formatISOWithTimeZone(tzid, candleLighting);See also new GeoLocation(name, latitude, longitude, elevation, timeZoneId)GeoLocation constructor with parameters for all required fields.
|
|
This is so exciting! I'll be reviewing over the next few days and will get back to you. A groyse yashkoyech! |
|
Please try |
|
A few initial notes: Engineering-wisethere are some typescript errors when loading the library, one having to do with Regarding that error, and even if it didn't throw, it would be better to not bundle the temporal-polyfill, but instead require the user to load a global-mutating polyfill on their own. About the GeoLocation constructor, would it make sense to roll that stuff into the HebCalLocation class? currently there are two separate and overlapping entities for location. IntegrationI'm working a bit on the integration, and it appears that candle-lighting time offset isn't being reflected in the output. This is probably a careless mistake on my part, but it's worth checking that the // before
candlelighting: boolean;
candleLightingMins: number;
// after
candleLighting: boolean | number;I suppose that's a matter of taste. I'll have some more notes on the zmanim themselves once those are resolved. |
|
Here's a demonstration of how the candle lighting times do not respect
|
|
Thanks for the quick feedback. It will take a few days to make changes. One thing we are considering is to match the KosherJava behavior of requiring a boolean opt-in to use elevation to adjust sunrise/sunset times. I am not expert on the halacha and I see some significant advantage to offering a consistent API to one that was informed by much research. |
|
We've been able to implement some of your suggestions in If you are using If you are using new Zmanim(gloc, date, useElevation)Initialize a Zmanim instance.
|
|
Very nice! Looks like I'll be able to use this at shul 💪
There are some compilation errors with rc.4. it looks like the esm build of noaa is actually a cjs file. see hebcal/noaa#1 and #365 errors:I did some cursory reading of the Stage 3 Temporal spec, and there are many references to the Hebrew calendar, although it seems that this is implementation dependent. So we can imagine a future where this code date.withCalendar('hebrew').add({ months: 1 });is supported by (hypothetical version numbers incoming) Chromium 130 and Node 25, but not by Firefox 130 or Node 24.
I hope I'm making a bit of sense here. |
|
Version 5.0.0 released. Closing this for now. |
Shalom uvrachah
Hebcal's zmanim calculations diverge significantly from the printed luchot commonly sold in jerusalem
without descending into a lengthy discussion of the halachic merits of the various approaches, it would be helpful to many gabbaim (and gabbai-affiliated nerds) to provide computed times which accord more-or-less with "the luach i bought in the shop"
my personal ignorance knows no bounds, nonetheless my cursory surveys of the relevant sugyas as well as the code suggest to me that if the elevation in jerusalem, or better yet at a given lat/long were taken into account in
@hebcal/solar-time, then it would be possible for the gabbai-affiliated to soothe the hesitations of the gabbaim themselves where@hebcal/coreintegrations are concernedThank you for your consideration
besoros tovos
The text was updated successfully, but these errors were encountered: