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 (towards the end of December), the length of the solar day would increase by about 31 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.5 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.

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 seconds around September 13 to a maximum of 24 hours and 31 seconds around December 23 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: My readers who follow the geocentric model will have to use their imagination to slightly modify the heliocentric based explanation above.

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

ZIP Codes and Zmanim – Use With Care

99557 ZIP code area (the largest in the USA)
99557 ZIP code area (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.

FAQ: How do I Calculate the Jewish/Hebrew Date for …?

Sunrise Calendar

This FAQ is now obsolete. Jewish Calendar Calculations are now supported. See the Zmanim API 1.3.0 Release announcement

Question:

How do I get the Jewish Date for … using the Zmanim API?

Answer:

The current version of the Zanim API does not support Jewish calendrical calculations. Zmanim are almost exclusively based on the solar calendar, so for example, the sunrise on February 8th this year in Montreal (or any other date and location), will be almost the same every year. for this reason there was little point (as far as zmanim) to support Jewish date calculations in the API. One of the only zmanim to rely on a Jewish date is the sof zman kidush levanah calculation, though there are some opinions that it is purely molad based, and this can be calculated without a Jewish calendar component to the API. This zman is obviously not currently implemented in the Zmanim API. I am currently working on adding Jewish date support to the API. The code is based off Avrom Finkelstein‘s no longer active HebrewDate project. I refactored a lot of the code and fixed a number of bugs. Anyone interested in alpha testing this code can download the latest Zmanim SVN code.
I mentioned that it “will be almost the same every year” and this is due the the approximate 1/4 day drift between the 356 day calendar year and the approximately 365.25 days actually present in the astronomical year, a discrepancy corrected every leap year. A future FAQ (probably a few of them) may delve specifically into this drift as well as general zmanim accuracy issues in detail.
If you are simply looking to convert a Hebrew date to Gregorian or Gregorian to Hebrew online without the API, try the JewishGen calendar conversion tools.

Zmanim Bug Report from the Land of the Midnight Sun

Midnight SunI was recently contacted by Jan Terje Johansen, a developer at Datek Wireless AS in Norway, with an interesting bug report. Datek uses the Zmanim API (the AstronomicalCalendar base class) to allow their clients (the power company and stadiums) to remotely (via a web interface) control streetlights and stadium lights throughout Norway using a wireless lighting control system that they developed. The zmanim code is used to allow setting the lighting times based on an offset of sunrise/sunset. For the technically curious, they are controlled primarily through GPRS, with SMS as fallback. A version under development uses ZigBee. The bug encountered was that for Tromsoe (Tromsø), Norway, as well as other areas within the Arctic Circle that experience the midnight sun, from May 13th to May 17th (the date of last rise of the season in Tromsoe), the zmanim API produced correct sunrise/set times, but the date component (The API returns all times as Java Dates, something that might change with v2.0 of the API that will target JDK 7 to take advantage of JSR-310 Date and Time API) was a day off. For non-automated systems, the date component is not important, but in their case it would cause the lights to go on/off on the wrong day. Jan provided a suggested patch that worked well. The actual fix I used was slightly different because I took advantage of the time spent on fixing the bug to refactor and simplify the code. This change as well as a few other changes are part of the Zmanim 1.1 beta release that will likely be released as a final release in a few days. Jan mentioned that:

“IMHO your API is easily the best and most accurate Open Source sunset/sunrise API out there”. He continued: “Officially (according to the Norwegian Meteorology Institute), the midnight sunset/sunrise is from May 20 to July 22 in Tromsoe, ie. the complete sun is above the horizon 24 hours. Parts of sun is visible 24 hours a day in Tromsoe from May 18th to July 25th. This is the same as in your calculations.” … “I have tested your calculations against other official midnight sunrise/sunset (part of sun) dates in Northern-Norway (North Cape, Hammerfest, Longyearbyen (78,049762N -15,458252E)) and they are spot on.”

In response to my question regarding his testing of the NOAACalculator versus the USNOCalculator he had an interesting and very practical answer

“We prefer to use USNO calculator as it is more in tune with the sunrise/sunset times printed in most newspapers. You see, our experience is that most users don’t look at the sun to determine sunrise/sunset but read the times in the newspaper. If our times don’t correspond to the printed ones, something is wrong with our system in their mind.”

Fix to NOAA Sunrise/Sunset Algorithm

The Zmanim API was developed from the ground up as an API which allows for easy plugging in of different algorithms. The Zmanim API ships with 3 “Calculator” implementations. Two calculators implement the US Naval Observatory’s algorithm, the SunTimesCalculator and the ZmanimCalculator (no longer available). Both produce identical zmanim using slightly different code and are included for comparison. There is also the JSuntimeCalculator (no loner available – see below information on the NOAACalculator), an implementation of the NOAA algorithm by Jonathan Stott. I was recently contacted by Eliezer Bulka who wanted to know why sunrise/sunset times generated by the NOAA algorithm were about 2 minutes off of the sunrise/sunset times generated by the NOAA JavaScript implementation that is the source of the JSuntimeCalculator. To compare apples and apples required modification of the NOAA JavaScript to allow entry of decimal latitude/longitude, and changing the output to display seconds. No change was made to the algorithm itself. I then ported the JavaScript directly to Java. This involved nothing more than slight syntax changes between the languages. Once this was done I noticed that the sun rise/set output from the Java port exactly matched the output of the NOAA JavaScript. Analysis of Jonathan’s code showed (or at least my interpretation of it did) that there were two areas that caused the difference. Once is that he used a slightly different method of computing the Julian date, a key part of the algorithm. His change includes the time of day as part of the calculation. The net result of this change is that solar time generated using his algorithm varies based on the time of day the calculation is run, something that is incorrect. This means that there can be a discrepancy of up to one calendar day. If the user calculated sunrise at 11:59 PM, sunrise would be calculated for the following day even if the user attempted to calculate it for today. In addition, the other calculations do not match the output of the matching NOAA code. I have deprecated the JSuntimeCalculator and in its place added the NOAACalculator that was the result of the direct port of the NOAA code, shoehorned into the Zmanim API Calculator interface. I ran some tests to compare the maximum and minimum discrepancy between the 2 implementations, and calculations for Lakewood, NJ, latitude 40.0828, longitude -74.2094 show a discrepancy of between a minute and 34 seconds to a minute and 37 seconds for sunrise and sunset across an entire year of sunrise and sunset calculations. I also compared the USNO algorithm to the new NOAA implementation and ended up with a maximum deviation of less than 30 seconds, something that had been about 1.5 minutes apart previously. While I do believe that the Julian date calculation is a bug, I do not know that this is a case as far as the rest of the calculation, but it is clear that it does not match the NOAA implementation that is was based on, and I recommend that you download the latest version that has the new NOAACalculator that fixes this issue. In addition to this fix, an additional patch will be released later this week that will address issues with calculations in the arctic circle. Stay posted for the next post.