Your comments

No, not yet. The Manitoba government decided this on September 17, 2026. The Effective Date is November 1, 2026.


Depending on how quickly the open source software that Hebcal uses gets patched, we may or may not get this updated before the November 1 date.


As a comparison, British Columbia officially announced it was ending seasonal time changes to adopt permanent Daylight Saving Time on March 2, 2026. They wisely made that decision more than 6 months in advance.

We have submitted an updated watch app to the Apple App Store and this should solve the problem for watchOS 27

Thank you for letting us know! We will work on getting an updated release out to support iOS 27

Did you try it out? It looks like Alexa Plus has made some changes and it might work for you. We just tested on both a standard Alexa and Alexa Plus device and we’re able to get the Hebcal skill to work again. 

Shabbat shalom and Shana Tova!

Hi Kay,


Thanks for reaching out! The evening entry you’re seeing is likely coming from the “Calendar reminder day before yahrzeit” option, which adds a separate reminder the evening before the actual yahrzeit date. This is in addition to the main all-day yahrzeit event.


To stop the evening entry from showing up, just uncheck the “Calendar reminder day before yahrzeit” box on the Download page before subscribing or downloading your .ics file. That should leave you with just the all-day event at the top of your calendar, without the extra evening reminder.


If you’ve already subscribed, you’ll want to re-subscribe (or re-download) after unchecking that box so the calendar feed updates.


Let me know if that resolves it!


Image 371



Hi Izzy, we did a bit more investigation today and think we may have fixed a bug to get Hebcal for Classic Alexa working again. Can you give it a try? Not sure it’s going to work well on the newer Alexa Plus devices but we would welcome your feedback. 

Shana Tova!

Thanks for the careful report! Good news: this reading isn't actually missing — and it's not technically a Rosh Hashana reading, which is why it's not in the holiday tables.

Rosh Hashana itself has no afternoon (Mincha) Torah reading. The reason there's a Mincha reading this year is simply that Rosh Hashana Day 1 falls on Shabbat, and on every Shabbat afternoon we read the opening aliyot of the coming week's parsha. The parsha after Rosh Hashana 5787 is Ha'azinu, so the Shabbat-Mincha reading is Deuteronomy 32:1-12 (exactly the three aliyot you listed).

We publish these Shabbat-afternoon readings (which are identical to the Monday/Thursday weekday readings) in our weekday leyning spreadsheet rather than the holiday tables, to avoid confusion between the Shabbat morning and Shabbat afternoon services. You'll find Ha'azinu 32:1-12 there. 


https://www.hebcal.com/sedrot/weekday-diaspora-5787.csv


More on which files contain what: https://www.hebcal.com/home/48/download-aliyot-breakdown-of-torah-readings


By contrast, Yom Kippur Mincha (Leviticus 18 + Jonah) is in the holiday tables, because that one is an intrinsic part of the day itself, read every year regardless of whether YK falls on Shabbat or another day of the week.

Thank you for the bug report! We found the error and it is now fixed. Please refresh the web browser if you still see the error. 

Shana Tova!

We see two birthdays in Google Calendar.

Image 369

If you’re still running into an issue, could you share the exact steps you took and what you saw (a screenshot would help), so we can pin down what’s different in your case?

There is a URL at the bottom of Google Calendar events, maybe you could send it by email to webmaster@hebcal.com and we can try to debug further?

Image 370

Hi hudis100,


Thanks for the report, but this actually works as expected — you can have multiple people’s birthdays listed on the same date. I just tested it myself and confirmed it:


https://www.hebcal.com/yahrzeit/edit/01m0r2aps88teecmme9vx1jj1a


Both Person1 and Person2 show up correctly as separate entries on 10 Feb 2026 (23rd of Sh’vat), and again in every subsequent year (5787, 5788, etc.). So there’s no bug here — the calendar handles overlapping dates fine.


If you’re still running into an issue, could you share the exact steps you took and what you saw (a screenshot would help), so we can pin down what’s different in your case?


Best, Michael