Time Zone Database – A Critical But Overlooked Zmanim Component

An important aspect of calculating accurate zmanim, is ensuring that the timezone information on the computer generating the zmanim is kept up to date. The volunteer maintained IANA time zone database (also known as the tz, zoneinfo or Olson database) is used globally by computers to store time zone information. Failure to keep up to date with the latest database will result in potentially generating zmanim that can be off by an hour or more in parts of the world. This time zone database is updated multiple times a year as locations around the world change their time zone information. Often changes are to the start and end of DST in various zones, but it sometimes includes year-round changes and newly introduced time zones that have rules differing from the geographic area around them. There is a general lack of awareness by zmanim software developers and system maintainers hosting zmanim apps, of the criticality of keeping this data up to date. A lack of keeping it up to date can result in the possibility of significant issues in zmanim calculations. Subscribing to the tz announcements mailing list will keep you up to date on the latest zone changes.

Timelines for Time Zone Data Updates

There are times when updates to the database are not released until after the changes take effect, and there are cases where the announcements are made very shortly before they take effect. An example of this was Lebanon’s 2023 change and reversal. On Mar 23, 2023 Lebanon announced that the DST that had been scheduled to start 2 days later on Mar 25 was being postponed to Apr 20. The IANA time zone database 2023b was released a day later on Mar 24 (2 days after the 2023a release). On Mar 27 they announced that they were moving to DST on Mar 29. On Mar 27, 2023c was released that restored an identical version to what had been released in 2023a.
Here is a timeline from the 2024a update for Kazakhstan (that has a small Jewish community impacted by the change). The change unified time zones for the entire country (that stretches 3,000 km /1,900 mi from east to west and geographically spans 4 time zones) from two (UTC+6 and UTC+5) to one UTC+5 zone. The timeline shows that despite being on top of things, you can’t always ensure that you are up to date.

  • Oct 19, 2023 – Discussions started about a proposed change to unify Kazakhstan on a single time zone. On Nov 12, 2023 – A draft decree about the change was published.
  • Dec 7, 2023 – The Kazakh Ministry of Trade and Integration announced the decree formalizing the changes.
  • Jan 19, 2024 – The changes were brought to the attention of the IANA Time Zone Database maintainers. It is not unusual for a delay like this in notifying the maintainers of a change.
  • Feb 1, 2024 – The time zone data change was released as 2024a.
  • Feb 2, 2024 – PECL timezonedb package was released.
  • Feb 4, 2024 – Moment.js‘s Moment Timezone releases v0.5.45 with the change.
  • Feb 14, 2024 – Android Mainline PR is merged. It would be available to most Android 10 devices within 24 hours. Older Android versions will have to wait for the next release.
  • Mar 1, 2024 – At the stroke of midnight, the clocks in part of Kazakhstan rolled back to Feb 29 at 11pm, resulting in a 25 hour leap year leap day.
  • Mar 6, 2024 – Node.js code was initially updated on the main branch on Feb 15 and an issue was opened on March 1 to have a release with the updated zone information. The non-LTS version 21.7.0 with the change was released om March 6. LTS versions 20.0.12.0 and 18.20.0 with the changed were released on March 26, 26 days after it took effect.
  • Mar 26, 2024 – Windows made the first update available via the March 2024 non-security preview update (that most do not install), 26 days after the change took effect.
  • Apr 9, 2024 – General availability of the Windows patch was released, 40 days after it took effect.

Updating Operating Systems and Various Languages

Below are the basics for keeping your system’s time zone database up to date. Note that there are times when the announcements of changes do not give much warning, and it is not always possible to keep perfectly up to date on some platforms. If you have information on languages and systems not covered here, please post information in the comments section.

  • Windows – Keep your Windows Updates up to date with optional updates. Systems set for security updates only, will never receive this update. See the information above on the windows portion of the timeline section.
  • Linux – Patches are usually available immediately after the release by the IANA team. Here is some info, but be sure to read the manuals before trying things. Ubuntu you would run something like sudo apt update && sudo apt upgrade -y tzdata. For Redhat it would involve something like sudo dnf update && dnf upgrade -y tzdata.
  • Android devices receive timely time zone updates for the devices current location, that will often not address issues in updating zone information for other locations. When generating zmanim for another location, care must be taken to ensure that the underlying zone database is up to date. Note that as of Android 10 (released in Sep, 2019 and currently only on about 20% of devices), the TZDB module was enhanced to update via the Mainline modules system that speeds up deployment of the updates. The Android tzdata process was enhanced late in 2023 to separate this to a standalone process that can be quickly updated multiple times a year without having to wait for other Mainline updates. Developers who want to package their own database to support older Android devices can package the Joda-Time for Android with their app, but they would have to ensure that they update their app every time a new zone database is released.
  • Java provides a TZUpdater tool (download) that can can be used to update the time zone database in Java. Having the latest Java release is not reliable enough, since there are time zone changes more often than the twice yearly release (though minor versions are updated more often).
  • JavaScript / TypeScript that use Moment would have to update their package.json and run npm install to receive updates. Luxon seems to use the operating system’s tzinfo. See info for Linux and Windows above. For other packages or libraries, research is needed.
  • PHP out of the box only updates the zone data on new releases, They maintain the timezonedb PECL package to deal with cases (like ours) where up to date zone data is needed, but it requires regular updates.
  • Python uses the operating system’s tzinfo. See info for Linux and Windows above. Alternatively, use pytz.
  • Ruby uses the operating system’s tzinfo. See info for Linux and Windows above.
  • Go uses the operating system’s tzinfo. A standalone copy can optionally be embedded in the Go executable.
  • iOS – I was unable to find any reliable information on the subject. Apple support declined to provide any information on the subject besides confirming that they push time zone updates in a timely manner.

For many systems, cron or other jobs are needed to keep the database updated on a regular schedule. For many, a restart of the system may be required.

Warning: Inexpensive shared hosting poses significant challenges to keeping your system zone database current. There are many aspects that you have no control over, and keeping the time zone database up to date is often not high on the agenda of risk-averse shared hosts.

Additional Complexities with Mobile Devices

There is an additional set of complexities for time zones for mobile devices. While this affects Macs and possibly Windows, very few if any are using native zmanim apps on those platforms.

  • One of the more common complaints about incorrect zmanim end up being caused by the device being set to the incorrect time zone. Most devices change their zone automatically, but some users manually change things and when they travel to a different zone without changing the zone, it results in incorrect zmanim. Mobile developers should explore detecting that the time zone on the device is different than the expected time zone, and alert the user to check the devices time zone setting, while ensuring that it does not have issues when there is no cellular signal (such as when flying).
  • Users in Israel may find themselves in areas where the phone sets the zone to Asia/Hebron or Asia/Gaza. Those areas have different DST rules than Israel, and will cause issues when the DST rules differ. A way to handle this situation in an app is to ensure that the app detects the setting of these two zones and use Asia/Jerusalem. I am unsure if Israeli cell providers return the expected zone setting in the West Bank (or Gaza).

Here is sample java.time.ZoneId code to address the second issue.

ZoneId zi = ZoneId.of("Asia/Hebron");
if((zi.getId().equals("Asia/Gaza") || zi.getId().equals("Asia/Hebron"))){
    zi = ZoneId.of("Asia/Jerusalem");
}

Historical List of Time Zone Changes

To give an idea of the scope of time zone changes (that some assume are rare or trivial), here is a list of changes to the database. The year 2009 sticks out with 21 published changes to the database, but as you can see, there are many years numerous changes published. This list excludes technical, historical (where there are corrections to the history of time zone changes years after the fact) and some irrelevant changes. There are many examples where a location made changes more than once a year, and those are not broken out. You can see some patterns here of countries that change very often. Ramadan is a cause of many changes in Muslim countries.

Year Updates Updated areas and Zones
2024 2 Kazakhstan (unified Asia/Almaty and Asia/Qostanay). Improve historical data for Mexico, Mongolia, and Portugal.
2023 4 Egypt, Palestine, Morocco, much of Greenland and Lebanon.
2022 7 Chile, Palestine, Iran, Jordan, Syria, Mexico (except near the US border), Chihuahua, Fiji, northern edge of Chihuahua, much of Greenland).
2021 5 South Sudan, Jordan, Samoa, Fiji, Palestine
2020 6 Morocco, Canada’s Yukon, Casey (Antarctica), Fiji, Palestine, Volgograd.
2019 3 Metlakatla, Palestine, Brazil, Fiji, Norfolk Island.
2018 8 São Tomé and Príncipe, Brazil, Palestine, North Korea, Volgograd, Fiji, most of Chile, Morocco, Qyzylorda (Kazakhstan) and Metlakatla, Alaska. New zone Asia/Qostanay.
2017 3 Mongolia, Chile, Haiti, Northern Cyprus, Fiji, Namibia, Sudan, Tonga, Turks & Caicos.
2016 10 America/Cayman, Asia/Chita, Palestine, Asia/Tehran, America/Metlakatla, Asia/Sakhalin, Azerbaijan, Chile, America/Caracas, Asia/Magadan, Africa/Cairo, Asia/Novosibirsk, Turkey, Pacific/Tongatapu, Tonga and Antarctica/Casey. New zones Europe/Astrakhan and Europe/Ulyanovsk, Asia/Barnaul, Asia/Tomsk, Europe/Kirov, Asia/Famagusta, Europe/Saratov.
2015 7 America/Cancun, Chile, Mongolia, Palestine, Egypt, Morocco, North Korea, Moldova Turkey, Norfolk, Fiji’s, Fort Nelson (BC, Canada).
2014 10 Turkey, Fiji, Crimea, Egypt, Morocco, Russia (Magadan Oblast, Zabaykalsky Krai, Chukotka Autonomous Okrug, Kamchatka Krai, Kemerovo Oblast, Samara Oblast), Udmurt Republic, Turks & Caicos, Fiji, Quintana Roo (Mexico), Chile. New zones Asia/Chita, Asia/Srednekolymsk and Pacific/Bougainville
2013 9 Chile, Haiti, Paraguay, Morocco, Palestine, Fiji, Tocantins, Israel, Jordan, Libya, Western Sahara, Acre, western Amazonas, Cuba. New Zones Asia/Khandyga, Asia/Ust-Nera, Europe/Busingen
2012 10 Armenia, Tokelau, Chile, Falkland Islands, Cuba, Morocco, Haiti, Fiji, Samoa, Palestine, Bahia, Tocantins, Israel, Jordan, Libya. New zone America/Creston
2011 14 America/North_Dakota/Beulah (Mercer County, North Dakota, Chile, Annette Island (Alaska), Samoa, Cuba, Turkey, Morocco, Palestine, Falkland Islands, Egypt, Russia, Newfoundland, Belarus, Ukraine, Tiraspol (Moldovia), Bahia (Brazil) and Fiji. New Africa/Juba (South Sudan) zones.
2010 15 Mexico, Paraguay, Bangladesh, Samoa, Fiji, Chile, Dhaka, Australian (Antarctic), Kamchaatka, Anadyr, Samara, Tunisia, Pakistan, Morocco and Egypt. New “Bahia_Banderas” time zone added.
2009 21 Cuba, Morocco, Tunisia, Argentina and Syria, Palestine, Jordan, Pakistan, Egypt, Bangladesh, Dhaka, Mauritius, Samoa, Fiji and Resolute
2008 9 Chile, Cuba, Argentina, Morocco, Pakistan, Choibalsan (Mongolia), Brazil, Iraq (abandons DST). Mauritius’s 2008 DST experiment, and some localized Brazilian time zone realignments.
2007 11 Asmara, Easter Island, Syria, Honduras, New Zealand, Australia (for 2008), America/Indiana, Brazil, Egypt, Iran, Venezuela, Cuba and Argentina.
2006 16 America/Indiana and America/New Brunswick (Canada), Haiti, Sri Lanka, Egypt, Syria, Uruguay, Honduras, Bermuda, Moncton, Blanc-Sablon and Western Australia.
2005 14 Uruguay, Kyrgyzstan …

Tefila Rules Added to KosherJava Zmanim Library

Kosel Picture 1932
Davening at the Kosel. This picture was taken by my grandfather Sidney (Nesanel) Siegfried on Aug 1, 1932 כ״ח תמוז תרצ״ב. This article was posted exactly 90 years to the day (Gregorian date) after the picture was taken.
The new TefilaRules class has been added to the KosherJava Zmanim Library. This will be included in the upcoming v2.4.0 release. The TefilaRules class was added in an effort to help zmanim calendar authors who sometimes require knowing if תחנון tachanun is recited on a specific day in order to set tefila times (such as mincha starting X minutes before shkiah, and a few minutes later if tachanun is not recited). It is also useful for siddur app creators. With many different minhagim (mostly chasidishe) about when tachanun is recited, the class currently supports 12 different options that can allow setting the rules for a majority of minhagim.
Yahrzeits such as 7 Adar, (Moshe Rabbeinu’s yahrzeit) or holidays celebrated by specific communities such as Purim Mezhbizh (Medzhybizh) celebrated on 11 Teves or Purim Saragossa celebrated on the 17th of Shevat (the Wikipedia date seems to be in error), are not (and likely never will be) supported by this class.
Other tefila related rules such as the existing Mashiv Haruach etc. rules were moved over from the JewishCalendar class to this new class where they have a more natural fit. The methods that were migrated over, were deprecated in the JewishCalendar class and will be removed in v3.0.0.

Key Methods in the TefilaRules Class

The following are the key methods in the new TefilaRules class.

Sample Code

TefilaRules tr = new TefilaRules();
JewishCalendar jCal = new JewishCalendar();
HebrewDateFormatter hdf = new HebrewDateFormatter();
hdf.setHebrewFormat(true); // Hebrew formatting
jCal.setJewishDate(5783, JewishDate.TISHREI, 1); // Rosh Hashana
System.out.println(hdf.format(jCal) + " - Is tachanun recited: " + tr.isTachanunRecitedShacharis(jCal));
jCal.setJewishDate(5729, JewishDate.SHEVAT, 21);
System.out.println(hdf.format(jCal) + " - is mashiv haruch recited: " + tr.isMashivHaruachRecited(jCal));
jCal.setJewishDate(5783, JewishDate.ADAR, 17);
System.out.println(hdf.format(jCal) + " - Is tachanun recited: " + tr.isTachanunRecitedShacharis(jCal));
tr.setTachanunRecitedWeekOfPurim(false); //default is true
System.out.println(hdf.format(jCal) + " - Is tachanun recited: " + tr.isTachanunRecitedShacharis(jCal));

Output:

א׳ תשרי תשפ״ג - Is tachanun recited: false
כ״א שבט תשכ״ט - is mashiv haruch recited: true
י״ז אדר תשפ״ג - Is tachanun recited: true
י״ז אדר תשפ״ג - Is tachanun recited: false

Rav Moshe Feinstein’s Zmanim Added to the KosherJava Zmanim API


Rav Moshe Feinstein is of the opinion that chatzos is at a fixed time all year round and is calculated based on the location’s longitude (in Lakewood, NJ it is at 11:56am / 12:56pm during DST). See Igros Moshe Orach Chaim vol 4 no. 20 who states

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

See the Igros Moshe for more details. The Aruch Hashulchan in Orach Chaim 233 no. 14 also calculates chatzos at a fixed time all year.

ודע דחצות היום תמיד שוה בקיץ ובחורף כשיכה המורה שעות י״ב אז הוי חצות היום וכן בלילה שהרי השעות שנתוספו או נתקצרו חציים מקודם חצות וחציים מלאחר חצות וא׳׳כ ממילא דהחצות לעולם עומדת בשוה

Rav Moshe also bases other zmanim calculations on this fixed local chatzos. As opposed to calculating shaaos zmaniyos from beginning to the end of a day, Rav Moshe calculates a number of zmanim based on half of the day starting or ending at fixed local chatzos (see Igros Moshe Orach Chaim vol 1, no. 23).

ומש״כ ידידי שהלוח של הישיבה אינו מדוקדק, הנה הוא בדיוק גדול ונכתב על דעתי. והטעם דהחצות של היום שהוא כשבא השמש באמצע הדרום שוה לעולם, אבל שני חצאי היום אינם שוים רק איזה ימים בשנה ולפעמים חצי הראשון גדול ולפעמים חצי האחרון. ולכן בין לקולא בין לחומרא מסתבר שנחלקו שש שעות עד חצות ושש שעות מחצות עד הערב. ולכן מש״כ ידידי שהוא שבשתא וטעות לא דבר נכונה שהוא אמת גמור וליכא ע״ז שום קושיא.

These zmanim are used in Mesivta Tiferet Yerushalayim (MTJ), Yeshiva of Staten Island and Camp Yeshiva of Staten Island. Code to calculate these Rav Moshe zmanim is now part of the latest v2.3.0 release of the KosherJava Zmanim API.
The following new zmanim are now included in the API:

Sample Usage

For developers, here is sample code that calculates the new zmanim. This should allow many zmanim apps to add Rav Moshe Feinstein’s zmanim with very little effort.

String locationName = "145 E Broadway, New York, NY";
double latitude = 40.7138;
double longitude = -73.9913;
double elevation = 11;
TimeZone timeZone = TimeZone.getTimeZone("America/New_York");
GeoLocation location = new GeoLocation(locationName, latitude, longitude, elevation, timeZone);
ComplexZmanimCalendar czc = new ComplexZmanimCalendar(location);
czc.getCalendar().set(1986, Calendar.MARCH, 23); //Rav Moshe's petirah
System.out.println("Sof zman shma alos 18° to fixed local chatzos: " + czc.getSofZmanShmaMGA18DegreesToFixedLocalChatzos());
System.out.println("Sof zman shma alos 16.1° to fixed local chatzos: " + czc.getSofZmanShmaMGA16Point1DegreesToFixedLocalChatzos());
System.out.println("Sof zman shma alos 90 to fixed local chatzos: " + czc.getSofZmanShmaMGA90MinutesToFixedLocalChatzos());
System.out.println("Sof zman shma alos 72 to fixed local chatzos: " + czc.getSofZmanShmaMGA72MinutesToFixedLocalChatzos());
System.out.println("Sof zman shma sunrise to fixed local chatzos: " + czc.getSofZmanShmaGRASunriseToFixedLocalChatzos());
System.out.println("Sof zman tfila sunrise to fixed local chatzos: " + czc.getSofZmanTfilaGRASunriseToFixedLocalChatzos());
System.out.println("Mincha gedola 30 minutes after fixed local chatzos: " + czc.getMinchaGedolaGRAFixedLocalChatzos30Minutes());
System.out.println("Mincha katana fixed local chatzos to sunset: " + czc.getMinchaKetanaGRAFixedLocalChatzosToSunset());
System.out.println("Plag hamincha fixed local chatzos to sunset: " + czc.getPlagHaminchaGRAFixedLocalChatzosToSunset());
System.out.println("Tzais 50 minutes after sunset: " + czc.getTzais50());

Calculating other fixed local chatzos based zmanim not included in the library (and not necessarily endorsed by this shitta) are very simple with the generic getFixedLocalChatzosBasedZmanim(Date startOfHalfDay, Date endOfHalfDay, double hours) method built to simplify calculating these zmanim. Here are a few examples.

//4 hours into a day based on half the day from alos 18° to fixed local chatzos
System.out.println("Sof zman tfila 18° to fixed local chatzos: " + czc.getFixedLocalChatzosBasedZmanim(getAlos18Degrees(), getFixedLocalChatzos(), 4); 
//plag hamincha based on the second half of the day starting at fixed local chatzos and ending 50 minutes after sunset
System.out.println("Plag hamincha fixed local chatzos to tzais 50 minutes: " + czc.getFixedLocalChatzosBasedZmanim(getFixedLocalChatzos(), getTzais50(), 4.75); 

I would like to thank Avraham David Gelbfish who requested this addition and provided instructions on the proper calculations used by these yeshivos in calculating the zmanim.

Taanis Bechoros Added to the KosherJava Zmanim API

Matzos
Years ago I posted the Calculating Erev Pesach Zmanim that discussed the addition of sof zman achilas chametz and sof zman biur chametz times to the API. Based on a request on the KosherJava project’s GitHub repository, a new isTaanisBechoros() method was added to the API. The Taanis Bechoros fast day usually occurs on Erev Pesach, but in years like this year (5781/תשפ״א – 2021) when Erev Pesach occurs on Shabbos, the fast is moved back to Thursday the 12th of Nissan. Erev Pesach occurs on Shabbos an average of once every 10 years. The frequency of such occurrences ranges from 3 to 20 years. It will next occur in the year 5785/תשפ״ה – 2025, followed 20 years later in the year 5805/תת״ה – 2045. The code is included in the new v2.2.0 release of the KosherJava zmanim library. The following code sample shows the basic usage of the new method.

JewishCalendar jd = new JewishCalendar();
HebrewDateFormatter hdf = new HebrewDateFormatter();
jd.setJewishDate(5781, JewishDate.NISSAN, 12);
System.out.println(jd.isTaanisBechoros());

Output:

true

The Yereim’s Bein Hashmashos

Rabbi Eliezer of Metz (known by his acronym The רא״ם Re’em), a disciple of Rabbeinu Tam, in his Sefer Yereim ספר יראים chapter 274, states that bein hashmashos starts the time it takes to walk three quarters of a mil before sunset, and ends at sunset.

פירוש משתשקע החמה דר׳ יהודה ור׳ נחמיה משמתחלת לשקוע שנוטה מעט ומכירים העולם שרוצה להכנס בעובי הרקיע … ולשון משתשקע משמע הקדמה … וכן נראה לי עיקר דמשתשקע החמה הוא קודם שקיעת החמה דעולא ולא כדברי רבינו יעקב … ואין להקפיד על צאת הככבים … אע״ף שאין הכוכבים נראים … שלילה גמור הוא כפירושי.

The Yereim’s opinion is brought down by other Rishonim including the Mordechai and Rav Alexander Suslin HaKohen in his Sefer Agudah. The Yereim is mentioned by the Bach as a reason for the minhag of starting Shabbos early. The Yereim’s times are not brought down by the poskim lehalacha.

The Time to Walk a Mil

The time to walk a mil is based on the Gemara in Pesachim 93b – 94a. The time ranges in the poskim and includes 18, 22.5 and 24 minutes. Three quarters of these mil times would be 13.5, 16.875 and 18 minutes. It should be noted that the Yereim is of the opinion that a mil is 24 minutes. The above mentioned Mordechai who quoted the Yereim is also of the same opinion. We will hopefully discuss in detail the various opinions on the time to walk a mil in a future article.

The Addition of the Yereim’s Times to the KosherJava Zmanim Library

As of the 2.1.0 release of the KosherJava zmanim library, the Yereim’s bein hashmashos times have been added to the KosherJava zmanim library/API. There are six variants of these zmanim that were added. These include the three exact minute offsets mentioned above, as well as the conversion of these three times to degrees (elevation angle, or solar zenith angle). The only prior degree based time for the Yereim that I am aware of is in Rabbi Yedidya Manet’s Zmanei Halacha Lema’aseh (זמני ההלכה למעשה מהרב ידידיה מנת). The Zmanei Halacha Lema’aseh charts calculate bein hashmashos in degrees based on the 18 minute (3/4 of a 24 minute mil, see p. 27 in the 4th ed. published in 2005), but does not clarify the degrees used. At Rabbi Yaakov Shakow’s recommendation, I used the refraction value of 31/60 or 0.516° that exists in Israel, as opposed to the global average of 0.566°. This more stringent refraction is mentioned in the Zmanei Halacha Lema’aseh (p. 11) and used in the לוח עתים לבינה Luach Itim Lebinah. I also slightly rounded the times. These small tweaks resulted in a trivial maximum 19 second chumra vs the non-rounded global average refraction. The resulting degrees of elevation angle for the Yereim’s bein hashmashos are 2.1°, 2.8° and 3.05°. Solar zenith angles are traditionally calculated using the sun’s position without adjusting for refraction and without accounting for the solar radius (i.e. it is the position of the center of the sun in a vacuum). This does not impact the calculated time, it is simply the convention used. In the upcoming 8th edition of הרב דוד יהודה בורשטין Rabbi Yehuda Burstein’s זמנים כהלכתם / Zmanim Kehilchasam he mentions that

הזמן הנ״ל של 18 דקות לפני השקיעה המישורית הוא הזמן רק במרכז א״י ביום הבינוני כנ״ל, ובכל מקום בכל יום מחשבין זאת לפי שיטת המעלות, דהיינו דבודקים כמה מעלות מעל האופק נמצאת השמש במרכז א״י ביום הבינוני 18 דקות לפני השקיעה המישורית, ואותו מספר מעלות של השמש מעל האופק בכל מקום בכל יום הוא הזמן של ״היראם״. ועוד יש להוסיף זמן ל״תוספת שבת״, ובזה יוצא ידי כל שיטות הראשונים ואשרי חלקו.

A future article will address the proper date to use for converting minute-based times to degrees below (or above) the horizon and show how to use the KosherJava Zmanim code to calculate this.
I would like to thank Rabbi Yaakov Shakow for his help and suggestions.

Sample Code

Below are code examples for all six variants of the Yereim’s Bein Hashmashos (spelled BainHashmashos in the code).

GeoLocation yerushalayim = new GeoLocation("Jerusalem, Israel", 31.778, 35.2354, 0, TimeZone.getTimeZone("Asia/Jerusalem"));
ComplexZmanimCalendar czc = new ComplexZmanimCalendar(yerushalayim);
Date bh18Min = czc.getBainHasmashosYereim18Minutes();
Date bh3Pt05Deg = czc.getBainHasmashosYereim3Point05Degrees();
Date bh16Pt875Min = czc.getBainHasmashosYereim16Point875Minutes();
Date bh2Pt8Deg = czc.getBainHasmashosYereim2Point8Degrees();
Date bh13Pt5Min = czc.getBainHasmashosYereim13Point5Minutes();
Date bh2Pt1Deg = czc.getBainHasmashosYereim2Point1Degrees();

SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd h:mm:ss a z"); //set the output format
sdf.setTimeZone(czc.getGeoLocation().getTimeZone()); //set the formatter's time zone
System.out.println("Bein Hashmashos 18 min:     " + sdf.format(bh18Min));
System.out.println("Bein Hashmashos 3.05°:      " + sdf.format(bh3Pt05Deg));
System.out.println("Bein Hashmashos 16.875 min: " + sdf.format(bh16Pt875Min));
System.out.println("Bein Hashmashos 2.8°:       " + sdf.format(bh2Pt8Deg));
System.out.println("Bein Hashmashos 13.5 min:   " + sdf.format(bh13Pt5Min));
System.out.println("Bein Hashmashos 2.1°:       " + sdf.format(bh2Pt1Deg));

The output of the above code (assuming that the calendar was set to March 16, 2020).

Bein Hashmashos 18 min:     2020-03-16 5:29:58 PM IST
Bein Hashmashos 3.05°:      2020-03-16 5:29:40 PM IST
Bein Hashmashos 16.875 min: 2020-03-16 5:31:05 PM IST
Bein Hashmashos 2.8°:       2020-03-16 5:30:51 PM IST
Bein Hashmashos 13.5 min:   2020-03-16 5:34:28 PM IST
Bein Hashmashos 2.1°:       2020-03-16 5:34:09 PM IST