OK, we have modified the server configuration to respect Cache-Control: no-cache. The change is live in production.

Just to reiterate the point made earlier: given the design of the Shabbat API, your application should not need to send that header in order to operate correctly. The Shabbat API is designed to serve the current week's results through Sunday at midnight in the timezone of the city specified by the geonameid parameter. The Expires header is set explicitly so our caching servers reduce load on our app servers while preserving full functionality for clients like yours.

You can, of course, feel free to send the header, and it will now do as you expect: it will bypass our caching layer and force our app server to recalculate the current week's Shabbat info.

Hi, thanks for contacting Hebcal. This sounds like a superb project!

You can definitely use our APIs to do all of what you describe above. Our licensing supports this and this 100% lines up with our mission to help help Jews to be observant of the mitzvot.

If you're planning to implement this with our web APIs, here are some pointers for what you'll want to use

• Display of the yahrzeit anniversaries: Yahrzeit + Anniversary REST API
• Zmainim clock/calendar: Zmanim (halachic times) API
• Weekly parasha: Jewish calendar REST API
• Daf Yomi schedule: Jewish calendar REST API

If you want to build your application entirely in JavaScript and want to avoid the Internet connectivity requirement for the REST API calls, you can also build the same product using our JS native APIs. The @hebcal/core package will do all of the above.

Here are the JavaScript equivalent APIs

• Display of the yahrzeit anniversaries: HebrewCalendar.getYahrzeit()
• Zmainim clock/calendar: Zmanim
• Weekly parasha: HebrewCalendar.calendar({sedrot: true}
• Daf Yomi schedule: HebrewCalendar.calendar({dafyomi: true})

We're aware of one company using Hebcal APIs to do this already; it's called Yahrzeitronix and their product is called YahrDisplay.

If for some reason you run into any issues, please let us know.

Hi, thanks for using Hebcal.

The short answer is that yes, you're receiving data that's 2 days old, but is still 100% correct with respect to what the Shabbat API is trying to do. Here are the headers we see when requesting that URL.

HTTP/2 200 
server: nginx/1.18.0 (Ubuntu)
date: Tue, 30 Aug 2022 16:45:32 GMT
content-type: application/json; charset=utf-8
content-length: 2447
vary: Accept-Encoding
etag: W/"1c9-JWtHF6a7KHzEBkekWL2HWbypsK0"
last-modified: Sun, 28 Aug 2022 09:46:10 GMT
expires: Sat, 03 Sep 2022 22:00:00 GMT
x-response-time: 3.829ms
x-varnish: 83568151 65035843
age: 197961
via: 1.1 varnish (Varnish/6.6)
access-control-allow-origin: *
accept-ranges: bytes

This is actually what we expect to see. The content is valid until 

Sat, 03 Sep 2022 22:00:00 GMT

Which is midnight Sunday in your timezone.

The longer answer is that our server config isn't respecting Cache-control: no-cache and we should fix that.

Update: we have identified the error and fixed it. You should have received a corrected reminder email for the event occurring in one week.

Our sincere apologies again for the error.

Thanks for using Hebcal and thanks for the bug report. Sorry about that!

Could you forward the reminder email to mradwin@hebcal.com so we can investigate further?

Thanks for using Hebcal! Sorry we aren't able to change the names of the holidays.

You could use an Excel or Google Sheets formula to change the name, for example

=REPLACE(A1, "Sukkot VI (CH"M)", "Shabbos Chol Hamoed")

We hope this helps. Good luck!

We've done a bit of investigation and have not been able to reproduce the problem. We tested on a Windows 11 desktop PC (unfortunately we don't have access to a Windows 10 PC) and tried with 3 browsers (Chrome, Edge, Firefox) and can't seem to reproduce.

Here's the link for 5783 candle lighting at a glance for Manchester, CT 06040. Can you try this link?

https://www.hebcal.com/shabbat/fridge.cgi?zip=06040&b=18&M=on&lg=s&year=5783