1. General
  2. Bugs
0
Fixed

Candle Lighting Times

ruben 4 years ago • updated by Michael J. Radwin 4 years ago • 3 
I have used hebcal for decades on GNU/Linux and also on thunderbird. It
has been accurate and rock solid.  I decided I needed to update the
thunderbird calander and the new calander, both as generated on the
website and the download is off on candlighting time by about 3 minutes,
and Havdalah, I have really no idea what is happening.  The commandline
seems correct to 72 minutes

7/31/2020 Candle lighting:  7:53
8/1/2020 Shabbat Nachamu
8/1/2020 Havdalah (72 min): 9:22
8/5/2020 Tu B'Av


Website:
Shabbat Times Brooklyn, New York, USA

    Candle lighting: 7:55pm on Friday, 31 July 2020
    Shabbat Nachamu occurs on Saturday, 1 August 2020
    This week's Torah portion is Parashat Vaetchanan
    Havdalah (72 min): 9:24pm on Saturday, 1 August 2020
    Tu B'Av occurs on Wednesday, 5 August 2020

City
Havdalah
nightfall (tzeit hakochavim)   ℹ️
minutes past sundown   ℹ️

I had to set it to 72 minutes, FWIW

I see a notwe about the website about making an adjustment to the
Shabbat times.  I think its not fixed :(

This is the OU data
Friday:
Alos 	4:15 A
Talis 	4:55 A
Sunrise 	5:52 A
Sof Zman Shema MA 	8:38 A
Sof Zman Shema GRA 	9:27 A
Sof Zman Tefila MA 	10:06 A
Sof Zman Tefila GRA 	10:38 A
Chatzos 	1:01 P
Mincha Gedola 	1:37 P
Mincha Ketana 	5:12 P
Plag Mincha 	6:42 P
Candle Lighting 	7:53 P
Sunset 	8:11 P
Tzeis 42 Minutes 	8:53 P
Tzeis 72 Minutes 	9:23 P
DAILY LEARNING
Times To Note

    Candle Lighting at 7:53 P

    Havdalah Tomorrow at 8:52 P

Events


Saturday:
Alos 	4:16 A
Talis 	4:56 A
Sunrise 	5:53 A
Sof Zman Shema MA 	8:39 A
Sof Zman Shema GRA 	9:27 A
Sof Zman Tefila MA 	10:06 A
Sof Zman Tefila GRA 	10:38 A
Chatzos 	1:01 P
Mincha Gedola 	1:37 P
Mincha Ketana 	5:11 P
Plag Mincha 	6:41 P
Sunset 	8:10 P
Havdalah 	8:52 P
Tzeis 42 Minutes 	8:52 P
Tzeis 72 Minutes 	9:22 P
Parsha 	Va'etchanan
DAILY LEARNING
Times To Note

    Havdalah at 8:52 P

Events


-- 
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002

http://www.nylxs.com - Leadership Development in Free Software
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013

Answer

Answer
Fixed
Michael J. Radwin 4 years ago

Another update: after a bunch of research, we've come to the conclusion that the sunset algorithm we were using in the JavaScript version of Hebcal wasn't accurate enough. As of today, we have swapped it out for a version that although less-commonly used in the JS world, seems to match both the previous C version and most other sources.

Some of the Hebcal event feeds are cached up to 1 week, so subscriptions on Google Calendar, iPhone, etc might not refresh until next Sunday.


https://www.hebcal.com/shabbat?geonameid=5110302&M=off&m=72

Shabbat Times Brooklyn, New York, USA

./hebcal -c --latitude 40,39 --longitude 73,56 --timezone America/New_York -m 72 | grep --context=2 '8/22/2020'

8/21/2020 Rosh Chodesh Elul

8/21/2020 Candle lighting: 7:26

8/22/2020 Havdalah (72 min): 8:55

8/28/2020 Candle lighting: 7:15

8/29/2020 Havdalah (72 min): 8:44


Answer
Fixed
Michael J. Radwin 4 years ago

Another update: after a bunch of research, we've come to the conclusion that the sunset algorithm we were using in the JavaScript version of Hebcal wasn't accurate enough. As of today, we have swapped it out for a version that although less-commonly used in the JS world, seems to match both the previous C version and most other sources.

Some of the Hebcal event feeds are cached up to 1 week, so subscriptions on Google Calendar, iPhone, etc might not refresh until next Sunday.


https://www.hebcal.com/shabbat?geonameid=5110302&M=off&m=72

Shabbat Times Brooklyn, New York, USA

./hebcal -c --latitude 40,39 --longitude 73,56 --timezone America/New_York -m 72 | grep --context=2 '8/22/2020'

8/21/2020 Rosh Chodesh Elul

8/21/2020 Candle lighting: 7:26

8/22/2020 Havdalah (72 min): 8:55

8/28/2020 Candle lighting: 7:15

8/29/2020 Havdalah (72 min): 8:44


Michael J. Radwin 4 years ago

Update: we've ported the "round Havdalah times up to nearest minute" feature back to C. It's available in hebcal 4.21 and later.


./hebcal --version

Hebcal version 4.21

./hebcal -c --latitude 40,39 --longitude 73,56 --timezone America/New_York -m 72 | grep --context=2 '8/1/2020'

7/30/2020 Tish'a B'Av

7/31/2020 Candle lighting: 7:53

8/1/2020 Shabbat Nachamu

8/1/2020 Havdalah (72 min): 9:23

8/5/2020 Tu B'Av

8/7/2020 Candle lighting: 7:45


Under review
Michael J. Radwin 4 years ago

Hi, thanks for using Hebcal.


One of the features of the new website is that it offers a radio button for Havdalah with two choices - tzeit or fixed minutes. The new default is Tzeit HaKochavim (solar depression of 8.5 degrees) vs. a fixed number of minutes (e.g. 72) after sunset, because it works more consistently across the globe.

Tzeit doesn't apply here, because it looks like in this case you're specifically choosing 72 minutes.

There are 3 things that could account for 1-2 minute differences in candle lighting and Havdalah times:

1. slightly different NOAA sunset calculators - the one we're using on the website now is implemented in JS. It was previously implemented in C. Both use double-precision floating point arithmetic, but there are so many constants and opportunities to round/truncate that there could be slight differences in the resulting number.


2. In JS, we truncate candle-lighting (Friday) times down to the nearest minute, and round Havdalah times up to the nearest minute. The idea here is that it's better to list candle-lighting time as 30 seconds earlier than strictly necessary, and for Havdalah it's better to wait an additional 30 seconds to end Shabbat/yontiff. So if the exact candle lighting time from the sunset engine (including seconds) was at 20:02:31 or even 20:02:59, we have always returned candle-lighting at 20:02 in both C and JavaScript. However, in JS we're operating a little differently for Havdalah times only. If the Havdalah calculation comes back as 21:17:29, JS will display 21:17, but if it were 21:17:30 through 21:17:59 we display 21:18. In the C version, we would display 21:17 for Havdalah even if the engine returned 21:17:59. Should we consider this a bug in the C version and backport the rounding feature to C? It's a 1- or 2-line code change.

3. Lastly, when comparing Hebcal to other sources like OU and Chabbad, most of the differences are explained by slightly different latitude/longitude definitions for a given city. Since 2013, Hebcal.com has been using lat/long definitions from GeoNames.org, which is available under a Creative Commons license. For the USA, we purchase a commercial ZIP code database from zip-codes.com.


In this particular case, it's likely that 1 minute of the 2-minute difference is accounted for reason #1, and the other minute is accounted for by reason #2.

Customer support service by UserEcho