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 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 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 June summer 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 earth’s 23.44° tilt results in the sun having to travel a drop farther (1.09° for every 1° of westward 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 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 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 westward 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.

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

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.

FAQ: Calculating the Baal Hatanya’s Shkiah

Baal Hatanya Zmanim

Please see the more recent and updated article Baal Hatanya’s Zmanim Added to KosherJava Zmanim Library for more current information.

Question:

How do I calculate the Baal Hatanya’s Zman for Shkiah as 4 minutes after sunset using the KosherJava Zmanim API?

Answer:

I was recently asked how to use the Zmanim API to calculate the Baal Hatanya’s opinion is that shkiah (halachic sunset) is 4 minutes after civil sunset. The assumption that the Baal Hatanya’s shkiah is a fixed 4 minutes after sunset is not that simple and will require a separate post to clarify. This zman should not be used lehalacha without consulting a rov. This post shows how to us the API assuming that it is a fixed 4 minutes after sunset. The technique to calculate this with the API is identical to the way getTzais72() would be calculated. The source of that method is

public Date getTzais72() {
return getTimeOffset(getSeaLevelSunset(), 72 * MINUTE_MILLIS);
}

The getTimeOffset(Date time, double offset) method in the base class AstronomicalCalendar is very simple:

public Date getTimeOffset(Date time, long offset) {
if (time == null || offset == Long.MIN_VALUE) {
return null;
}
return new Date(time.getTime() + offset);
}

The getTimeOffset method simply adds the number of milliseconds of the offset to the raw time of the zman and returns it as a date. While using the API itself is not needed for such a simple calculation, here is how it would be used:

String locationName = "Jerusalem";
double latitude = 31.778; // Har habayis
double longitude = 35.2354;// Har Habayis
double elevation = 0;
TimeZone timeZone = TimeZone.getTimeZone("Asia/Jerusalem");
GeoLocation location = new GeoLocation(locationName, latitude, longitude, elevation, timeZone);
ZmanimCalendar zc = new ZmanimCalendar(location);
Date baalHatanyaShkiah = zc.getTimeOffset(zc.getSeaLevelSunset(), 4 * 60000);
System.out.println("Baal Hatanya Shkiah: " + baalHatanyaShkiah);

Adding it to the API itself would be even simpler:

public Date getShkiahBaalHatanya() {
return getTimeOffset(getSeaLevelSunset(), 4 * MINUTE_MILLIS);
}

At some point in the future I may (doubtful) add this time to the API itself. The zman is not commonly used, and the Chabad calendars that I have seen all use regular sunset.

Update on ‍‍July 5, 2015 – י״ח תמוז תשע״ה: This article was updated to clarify that the Baal Hatanya’s opinion may not be a fixed 4 minutes, but that the post was showing how to use the API to calculate it based on the questioner’s assumption that it was a 4 minute zman.
Update on Dec 14, 2018 – ו׳ טבת תשע״ט: This article was superseded with the more recent and corrected article Baal Hatanya’s Zmanim Added to KosherJava Zmanim Library.

FAQ: Outputting Zmanim for A Different Time Zone With the the Zmanim API

Question:

Why does the output of zmanim for a different time zone appear incorrect?

Answer:

One of the common issues encountered by developers using the API is that zmanim generated for a different time zone than the user’s time zone may return output that appears incorrect. For example a user in Lakewood, NJ trying to calculate sunrise for Yerushalayim may attempt to use the following code:

String locationName = "Jerusalem";
double latitude = 31.778; // Har habayis
double longitude = 35.2354;// Har Habayis
double elevation = 0;
TimeZone timeZone = TimeZone.getTimeZone("Asia/Jerusalem");
GeoLocation location = new GeoLocation(locationName, latitude, longitude, elevation, timeZone);
ZmanimCalendar zc = new ZmanimCalendar(location);
zc.getCalendar().set(2011, Calendar.FEBRUARY, 8);
System.out.println("Sunrise: " + zc.getSunrise());
System.out.println("Sunset: " + zc.getSunset());

While you would expect a sunrise of 6:27:41 AM and sunset of 5:19:19 PM, running this code on a computer anywhere in the Eastern Standard time zone would generate the following time that appears to be 7 hours early:

Sunrise: Mon Feb 07 23:27:41 EST 2011
Sunset: Tue Feb 08 10:19:19 EST 2011

The issue is simple, and the sunrise and sunset returned above are actually accurate. Zmanim are returned by the Zmanim API as a Java Date object that represents a moment in time (stored internally by Java as Unix Time – the number of milliseconds since the January 1, 1970 GMT). Sunrise in Yerushalayim on February 8th actually happens at 11:27:41 PM on February 7th EST. Java is simply outputting the Date as a String formatted to the users default time zone (EST in this example). The user probably intends to output the time in IST – Israel Standard Time (“Asia/Jerusalem” in the Olson database). To do this you have to output the zmanim using a formatter set to use the “Asia/Jerusalem” time zone.

DateFormat zmanimFormat = new SimpleDateFormat("EEE MMM dd HH:mm:ss z yyyy");
zmanimFormat.setTimeZone(location.getTimeZone());

System.out.println("sunrise: " + zmanimFormat.format(zc.getSunrise()));
System.out.println("sunset:" + zmanimFormat.format(zc.getSunset()));

will output the expected

sunrise: Tue Feb 08 06:27:41 IST 2011
sunset:Tue Feb 08 17:19:19 IST 2011

Below is the full code example.

import net.sourceforge.zmanim.*;
import net.sourceforge.zmanim.util.*;
import java.util.TimeZone;
public class FormatZmanim{
	public static void main(String [] args) {
		String locationName = "Jerusalem";
		double latitude = 31.778; //latitude of Har habayis
		double longitude = 35.2354; //longitude of Har Habayis
		double elevation = 0; //optional elevation
		//use a Valid Olson Database timezone listed in java.util.TimeZone.getAvailableIDs()
		TimeZone timeZone = TimeZone.getTimeZone("Asia/Jerusalem");
		//create the location object
		GeoLocation location = new GeoLocation(locationName, latitude, longitude, elevation, timeZone);
		ZmanimCalendar zc = new ZmanimCalendar(location); //create the ZmanimCalendar
		zc.getCalendar().set(2011, Calendar.FEBRUARY, 8); //set the date
		DateFormat zmanimFormat = new SimpleDateFormat("EEE MMM dd HH:mm:ss z yyyy"); //Create the formatter
		zmanimFormat.setTimeZone(location.getTimeZone()); //set the formatter's time zone
		System.out.println("sunrise: " + zmanimFormat.format(zc.getSunrise()));
		System.out.println("sunset:" + zmanimFormat.format(zc.getSunset()));
	}
}