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 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 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.

I expect a future post on the subject at some point in the future.

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);
omplexZmanimCalendar 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 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 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 - the largest in the USA
The 99557 ZIP code in Alaska – 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.

The Novaya Zemlya Effect’s Impact on Zmanim

Novaya Zemlya Effect Distorted Sun
A Distorted Sun Caused by the Novaya Zemlya Effect (Credit: Brocken Inaglory)
You may have seen disclaimers on zmanim calendars warning of up to a 2 minute inaccuracy due to weather and atmospheric conditions. Atmospheric refraction from the earth’s atmosphere, causes the sun to be visible on average about 3 minutes earlier at sunrise, and about 3 minutes later at sunset (compared to a vacuum) due to the atmosphere bending the sunlight upwards towards the viewer. The 3 minutes is only an average, and it can swing widely due to weather and atmospheric conditions. The typical variance caused by “non-average” atmospheric conditions would usually be within 2 minutes, resulting in the 2 minutes mentioned in the disclaimers. This 2 minute variance is during usual conditions, though there are conditions that would greatly increase this time.

Refraction Explained

Refraction at Sunset
Refraction at Sunset
When the sun’s rays traveling through the vacuum of space hit the earth atmosphere, they slow down and bend upwards towards the observer resulting in the sun being visible earlier (than in a vacuum) in the morning, and later at sunset.
Straw appearing to be bent due to refraction
Straw appearing to be bent due to refraction
Refraction of the sun’s rays is not a one stage refraction, but as the sun passes through increasingly dense layers of atmosphere, the amount of refraction increases with each thicker layer. This can be seen in the diagram of refraction at sunset above. The apparent position of the sun near sunset in the image (exaggerated in the image) is height of the sun as it appears to the user, though in reality the sun is below the horizon. Refraction can easily be observed by looking at a straw in a partially filled glass. The straw appears to bend (or be broken) at the point it enters the water. This is due to increased refraction in water versus air.

Complexity in Calculating Refraction

Since the amount of refraction depends on the pressure (the more dense the atmosphere is, the greater the refraction), temperature (hot air is less dense and refracts less) and to a lesser degree humidity (water vapor in the air impacts the refraction) in each layer of the atmosphere, calculating refraction is complex and requires very detailed meteorological information on the current conditions in each layer of the atmosphere in the area being computed. This can’t be done accurately in advance, and even calculations for the current day require readings from weather balloons at multiple elevations for accurate measurement, something not very practical (though the Lakewood vasikin minyan (likely done elsewhere as well) manually adjusts the hanetz hachama time each morning based on the weather). For this reason, zmanim (as well as civil sunrise and sunset) calculations usually use a global average refraction of 34′ of a degree, or 0.5666°. The global average atmospheric refraction accounts for sunrise being between 3:01 minutes earlier (during the solstice), and 2:29 minutes earlier (during the equinox) in Yerushalayim, as opposed to the value in a vacuum (the difference depends on where in the world you are, in Lakewood, NJ the range is 3:29 – 2:57). This average atmospheric refraction is not very accurate but is commonly used since it is complex to calculate local averages. More accurate refraction figures can be calculated for local and seasonal atmospheric models, and these have been shown to be accurate to within 15 seconds 90% of the time in the case of summer and winter subtropical models used in a study in Israel. See Using a Digital Terrain Model to Calculate Visual Sunrise and Sunset Times by Rabbi Chaim Keller and Dr. John K. Hall for additional details.

Inversion and the Novaya Zemlya Effect

Under usual conditions, the atmosphere gets colder at elevation, with the warmest air being closest to earth. An inversion condition is where there is a layer of cold air under a layer of warmer air. When there is an inversion over a large area (greater than 400 km), the solar rays get ducted in the lower colder air layer (see image below) and produce an extreme refraction. This is known as the Novaya Zemlya effect and produces a solar mirage resulting in the somewhat visually distorted sun being visible much earlier than expected (see top image).

Novaya Zemlya Effect Refraction Diagram (Credit: W. H. Lehn)
Novaya Zemlya Effect Refraction Diagram
While typically a phenomena in the polar regions, a study by the University of Calgary showed that refraction can have a significant affect on zmanim even in non-polar areas. In the 2003 study (Variability in the Astronomical Refraction of the Rising and Setting Sun), they observed that the sunrise on January 10, 1991 appeared almost 12 minutes earlier than expected. The paper mentions:

On rare occasions, the Sun appeared to rise much earlier or set much later than predicted by such publications as the Tables of Sunrise, Sunset, and Twilight (USNO 1962). In our study, the sunrise of 1991 January 10 was almost 12 minutes early. This phenomenon is known as the Novaya Zemlya solar mirage (Lehn 1979). It appears to be caused by a geographically extensive temperature inversion within the boundary layer of the atmosphere. The resulting vertical density profile causes the sunlight to be ducted around the curvature of the Earth. For the purpose of this study, we defined anomalously large astronomical refraction to be an event with refraction greater than 1°. A total of 12 anomalous events were recorded (2.9%).

While these typically occur in cold areas, they can happen in other areas as well. The study authors mention that

The majority of the anomalous events took place in the cold months. Nine of the 12 events occurred between November 1 and April 30, with January having five events. At the time of the events, the average surface temperature was -10.9°C, and all events occurred with surface-inversion conditions. Surface inversions tend to form with overnight surface radiative cooling through a dry atmosphere. Typically, they persist into the early morning, even after sunrise. Even though most of the events took place in the cold parts of the year, the data suggest that the Novaya Zemlya solar mirage may not be an exclusively cold-weather or polar phenomenon. Four of the events occurred with a surface temperature greater than 0°C. One event took place 2 days after the summer solstice.

Refraction at Sunrise VS Sunset

The University of Calgary study found that extreme refraction is an order of magnitude more common at sunrise than sunset. The reason for the difference between sunrise and sunset is that

This may be because the lower atmosphere is better mixed during the day as a result of solar heating leading to a dry adiabatic lapse rate in the boundary layer. Anomalously large astronomical refraction events the “Novaya Zemlya solar mirage” occurred about 3% of the time and were an order of magnitude more common at sunrise than sunset.

That said, The Novaya Zemlya effect does occur at sunset and in warm climates as seen in this video of sunset in San Francisco. Sadly, the video does not include information on how long it delayed sunset.

Halacha

Halachically sunrise and sunset times depend on when we can see the sun, and not when it is at the horizon. As mentioned above, the average global refraction of 34′ results in sunrise appearing about 3 minutes earlier and sunset 3 minutes later later than in a vacuum, and this refraction (or other similar refraction values) is what is used in all calendars (both halachic and civil). The fact that there is such potential for variation in weather conditions, and that the global average is likely not what is present where the zmanim are being calculated, is the reason that many luchos (zmanim calendars) have disclaimers about accuracy. Many calendars round off their zmanim without showing seconds due to the inability to accurately calculate zmanim because of refraction variations. Lahalacha the impact of earlier or later sunrise is limited to vasikin minyanim. A separate article may be needed to actually discuss sof zman krias shema and other zmanim’s relation to sunrise and sunset VS the actual position of the sun in the sky (1/4 of the way across its path for sof zman krias shema). The halachic impact of refraction at sunset is much greater since it impacts the day/night boundary, but those are much rarer.
Now to the big question, does extreme refraction such as the Novaya Zemlya effect impact zmanim? The fact that it rarely impacts sunset, means that it almost academic since predicting the inversion before a vasikin minyan starts is impractical. In a conversation with one posek a number of years ago, he felt that the Novaya Zemlya Effect should not impact zmanim lahalacha due to the fact that unusual occurrences should not be factored in, and because the distorted sun is not considered the sun as far as zmanim. I would appreciate being notified if anyone receives a psak halacha on this question.

Zmanim For Kiddush Levana Before Shavuos 5778

Crescent_MoonRarely do you find Zmanim that are days apart based on your location, but this year, that is exactly what will happen. With Shavuos falling on a Sunday and Monday, we end up with a “3 day Yom Tov” that impacts the earliest time / zman that Kiddush Levana can be said (for those who say it 3 days after the molad). With the minhag that Kiddush Levana is not said on Shabbos or Yom Tov, there is only a small chance to say Kiddush Levana on Thursday night based on your location. The molad for the month of Sivan was at 6:00:23 am in Yerushalayim (5:21 am and 6 chalakim local mean time using the traditional calculation) on Rosh Chodesh Sivan, Tuesday May 15. This results in Techilas zman kiddush levana 3 days later at 6:00:23 am Friday morning May 18. This is well after the moon sets, and actually after the sun rises. It can’t be said on Friday night, or Motzai Shabbos since it is Yom Tov. The earliest it can be said in Israel is on Sunday night. Much farther west in NY or Lakewood, NJ, where 2 days of Yom Tov are observed you get close to being able to say it on Thursday night, but not close enough. Kiddush Lavena could theoretically be said at 11:00 pm Thursday night, but by that time, the moon will already set (at 10:38 pm in Lakewood, and at 10:39 pm in Brooklyn, NY) and you end up having to wait until Monday night to say Kiddush Levana. From 11:00 pm on Monday night, even those who do not recite Kiddush Levana until 7 days after the molad can say it (moonset is at 1:20 am). Traveling farther west to Cleveland, OH with a moon set of 11:14 pm would seem to allow Kiddush Levana to be said on Thursday night. However with the moon this close to the horizon, it would be almost impossible to see the moon and say Kiddush Levana on Thursday night before the moon set. Going a little farther west, we hit the first locations that can say Kiddush Levana on Thursday night. Chicago (and other areas along their longitude) with a techilas zman Kiddush Levana of 10:00 pm and a moonset of 10:40 pm would likely be the first places in the world to say Kiddush Levana this year.
Thus, from Chicago to the west coast of the USA and Canada, Kiddush Levana can be said 3 days before Israel, and 4 days before Europe and eastern USA and Canada.

Parsha Code Removed from KosherJava Zmanim Calendar API

Java CalendarDue to licensing issues that were brought to my attention last year, the parsha code was removed from the Zmanim API on Aug 22, 2016. In the future I may release the parsha code as a standalone module under the GPL license, or create a new LGPL implementation. To understand this more clearly, the current Zmanim API is licensed under the LGPL, while the parsha code contained some GPL code that had to be removed in order to retain the LGPL license. I would welcome any code submission for parsha code that could be released under the LGPL.

FAQ: Different Parshas Hashavua in Eretz Yisrael Than Chutz La’aretz

Question:

Why does the KosherJava Zmanim API seem to sometimes return the incorrect parshas hashavua in Israel?

Answer:

I have had a number of inquiries this year about the incorrect Parshas Hashavua being returned by the API. In all cases this has been a complaint for Eretz Yisrael and not Chutz La’aretz. The explanation is pretty simple and covered in the API documentation for the JewishCalendar class, but may not be clear to all. When the first day of Pesach occurs on a Shabbos, as it did this year (5775), the last day of Pesach in Eretz Yisrael is on a Friday. The following day is a regular Shabbos in Eretz Yisrael with the usual krias hatorah, but in chutz la’aretz it is the 8th day of Pesach, resulting in Pesach kriah. The following weeks will have different krias hatorah in Eretz Yisrael vs chutz la’aretz, and this will continue for a number of weeks until a double parsha in chutz laaretz is added to equalize the parsha. This last occurred in 2012 (before the release of the calendar functionality in the Zmanim 1.3 release), and will occur again next year. If you are coding to display the Parshas Hashavuah for use in Israel, it is important to set the inIsrael flag (it defaults to false).

JewishDate.setInIsrael(true);

A fuller example showing how to set the indicator and showing the comparison of Eretz Yisrael and Chutz Laaretz this year can be seen in this example.

JewishCalendar israelCalendar = new JewishCalendar(5775, JewishDate.NISSAN, 7);
israelCalendar.setInIsrael(true); //set the calendar to Israel
JewishCalendar chutsLaaretzCalendar = new JewishCalendar(5775, JewishDate.NISSAN, 7);
chutsLaaretzCalendar.setInIsrael(false); //not really needed since the API defaults to false
HebrewDateFormatter hdf = new HebrewDateFormatter();
System.out.println("Date\tChutz Laaretz / Eretz Yisrael"));
for(int i = 0; i < 57; i++){
	israelCalendar.forward(); //roll the date forward a day
	chutsLaaretzCalendar.forward(); //roll the date forward a day
	if(chutsLaaretzCalendar.getDayOfWeek() == 7){ //ignore weekdays
		System.out.println(hdf.formatParsha(chutsLaaretzCalendar) + "\t" + hdf.formatParsha(israelCalendar) + " \\ " + hdf.format(chutsLaaretzCalendar));
	}
}

the output of this is

Date               Chutz Laaretz / Eretz Yisrael
8 Nissan, 5775     Tzav / Tzav
15 Nissan, 5775     / 
22 Nissan, 5775     / Shmini
29 Nissan, 5775    Shmini / Tazria Metzora
6 Iyar, 5775       Tazria Metzora / Achrei Mos Kedoshim
13 Iyar, 5775      Achrei Mos Kedoshim / Emor
20 Iyar, 5775      Emor / Behar
27 Iyar, 5775      Behar Bechukosai / Bechukosai
5 Sivan, 5775      Bamidbar / Bamidbar

It should be noted that this discrepancy is not rare and happens about 25% of the calendar years.