I am noticing a very large change in the time for sunrise (and sunset) between 02-28 and 03-01. This seems to be true in every calendar year, which leads me to believe there is a bug somewhere in the Hebcal code that is causing this. My hunch is that February only having 28 (or 29) days might have something to do with it.

For example, if we look at sunrise in 07666 for 2021-02-28 (https://www.hebcal.com/zmanim?cfg=json&start=2021-02-28&geo=zip&zip=07666) it is 06:36, but for 2021-03-01 (https://www.hebcal.com/zmanim?cfg=json&start=2021-03-01&geo=zip&zip=07666) it is 06:30. That's a difference of 6 minutes in just one day, whereas the differences between the previous day (2021-02-27) is 1 minute and subsequent day (2021-03-02) is only 2 minutes.

I brought this up to @nkasimer who created a spreadsheet of the change in sunrise times for 999 days in 07666 starting from 2021-01-01. As you can see, the changes correspond nicely with the seasons and are usually only a couple of minutes, but the difference between 02-28 and 03-01 in any year is always 6 six minutes, an obvious outlier.

Here is a link to that spreadsheet and a screenshot of the chart.

https://docs.google.com/spreadsheets/d/1OpQTPeeG1oyb29XctjGekoZE3OVjv7gvykPVcJC7mYw/edit?usp=sharing

Thanks again! Fixed in https://github.com/hebcal/hebcal-es6/issues/22

Created an issue on the wrong project, so reposting here.

Original ticket: https://github.com/hebcal/hebcal/issues/213

Changes deployed.

https://www.hebcal.com/zmanim?cfg=json&start=2021-02-27&end=2021-03-02&geo=zip&zip=07666

Closing this bug. Some URLs may be cached for up to 30 days so if you find something that looks wrong, check the Age HTTP header.

Agreed - the problem was indeed exactly as you describe. I've implemented a fix and have published new npm package @hebcal/[email protected]. I will deploy to the website tomorrow.

Started taking a closer look into the solar-calc library and I think this issue is arising from a bug in how it calculates the Julian date. Here are some examples from Dec 31 2020 to Mar 2 2021.

Dec 31 2459214.5 Jan 01 2459213.5 Feb 27 2459269.5 Feb 28 2459270.5 Mar 1 2459274.5 Mar 2 2459275.5

When you compare these dates to the dates provided by an online conversion tool such as https://www.onlineconversion.com/julian_date.htm you can see that everything from Jan 1 to Feb 28 is incorrect.

Thanks. We will do some investigation. We are using the solar-calc JavaScript library, and you have provided helpful guidance.

I tested the hebcal command line program and this problem does not appear to occur.

Since this issue is actually on hebcal-es6, I've opened a new ticket there. https://github.com/hebcal/hebcal-es6/issues/22

Feel free to close this ticket, but the screenshots and information provided here will be useful in getting to the bottom of this issue.

Created an issue on the wrong project. So reposting here: https://github.com/hebcal/hebcal/issues/213

Digging a little deeper, I calculated sunrise times using the solar-calc nodejs package (https://www.npmjs.com/package/solar-calc) that the Hebcal Zmanim API is using and it appears that this is where the problem is coming from.

Attached is a text file and corresponding chart of the sunrise times for the same date range and location as above, which shows the gradual drift in January and February followed by a significant drop off on March 1.

Thanks to @nkasimer for the chart!

solarcalc_sunrise_teaneck.txt

To add some additional data--I compared a year's worth of sunrise times from hebcal and the Python zmanim library. For most of the year there's fairly consistent error, which I assume is attributable to a combination of rounding, slightly different locations, refractions models, etc. But throughout Jan and Feb the difference increases significantly over time, falling abruptly to a fairly consistent level March through December. The y axis is difference in sunrise times in minutes.

I am noticing a very large change in the time for sunrise (and sunset) between 02-28 and 03-01. This seems to be true in every calendar year, which leads me to believe there is a bug somewhere in the Hebcal code that is causing this. My hunch is that February only having 28 (or 29) days might have something to do with it.

For example, if we look at sunrise in 07666 for 2021-02-28 (https://www.hebcal.com/zmanim?cfg=json&start=2021-02-28&geo=zip&zip=07666) it is 06:36, but for 2021-03-01 (https://www.hebcal.com/zmanim?cfg=json&start=2021-03-01&geo=zip&zip=07666) it is 06:30. That's a difference of 6 minutes in just one day, whereas the differences between the previous day (2021-02-27) is 1 minute and subsequent day (2021-03-02) is only 2 minutes.

I brought this up to @nkasimer who created a spreadsheet of the change in sunrise times for 999 days in 07666 starting from 2021-01-01. As you can see, the changes correspond nicely with the seasons and are usually only a couple of minutes, but the difference between 02-28 and 03-01 in any year is always 6 six minutes, an obvious outlier.

Here is a link to that spreadsheet and a screenshot of the chart.

https://docs.google.com/spreadsheets/d/1OpQTPeeG1oyb29XctjGekoZE3OVjv7gvykPVcJC7mYw/edit?usp=sharing

It seems that when the 15th of Adar falls on Shabbat, Hebcal treats Shushan Purim as being on Sunday and not on Shabbat. While some Purim stuff is pushed off to Sunday, there are still Shushan Purim things that happen on Shabbat (e.g. Al HaNisim). So when Shushan Purim is on Shabbat Hebcal shows the leyning for Sunday as being the Purim leyning--but in places that celebrate Shushan Purim this is actually read on Shabbat, not on Sunday.

Possible solutions would be to say that, in years like this, both Shabbat and Sunday are Shushan Purim, with leyning only returning for the one on Shabbat (possibly with the haftarah read in places with Shushan Purim, which is the one for Zakhor I believe). Or to have Shabbat be Shushan Purim, and Sunday listed as "Purim Meshulash".

This is for the Unix CLI app? Or for the website? iCalendar reminders or email reminders?

Bumps jsdoc-to-markdown from 6.0.1 to 7.0.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/jsdoc2md/jsdoc-to-markdown/releases">jsdoc-to-markdown's releases</a>.</em></p> <blockquote> <h2>v7.0.0</h2> <p>This is a refresher release - there are no API or functional changes.</p> <h2>Breaking change</h2> <ul> <li>Dropped support for Node.js versions less than v14.</li> </ul> <h2>Minor updates</h2> <ul> <li>Refreshed dependency tree.</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/jsdoc2md/jsdoc-to-markdown/commit/eafd4443f098a0d7351ba37bb0064f4a9bce318e"><code>eafd444</code></a> 7.0.0</li> <li><a href="https://github.com/jsdoc2md/jsdoc-to-markdown/commit/363f8bd2061fa38c4c8645b3ce8615a6d3e00776"><code>363f8bd</code></a> drop support for node < v14.. upgrade deps.</li> <li>See full diff in <a href="https://github.com/jsdoc2md/jsdoc-to-markdown/compare/v6.0.1...v7.0.0">compare view</a></li> </ul> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

</details>

Bumps jsdoc-to-markdown from 6.0.1 to 7.0.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/jsdoc2md/jsdoc-to-markdown/releases">jsdoc-to-markdown's releases</a>.</em></p> <blockquote> <h2>v7.0.0</h2> <p>This is a refresher release - there are no API or functional changes.</p> <h2>Breaking change</h2> <ul> <li>Dropped support for Node.js versions less than v14.</li> </ul> <h2>Minor updates</h2> <ul> <li>Refreshed dependency tree.</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/jsdoc2md/jsdoc-to-markdown/commit/eafd4443f098a0d7351ba37bb0064f4a9bce318e"><code>eafd444</code></a> 7.0.0</li> <li><a href="https://github.com/jsdoc2md/jsdoc-to-markdown/commit/363f8bd2061fa38c4c8645b3ce8615a6d3e00776"><code>363f8bd</code></a> drop support for node < v14.. upgrade deps.</li> <li>See full diff in <a href="https://github.com/jsdoc2md/jsdoc-to-markdown/compare/v6.0.1...v7.0.0">compare view</a></li> </ul> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

</details>

feature request: Relative holiday reminders.

e.g. define reminder as "1 week before passover" or "1 hour before every holiday" h/t: request from B.R.

In my nodejs project, I take a gif image, break up each frame into png files (using gif-frames), then apply an overlay to them then recombine then into an apng. When the frames have a transparent background it seems UPNG stacks the frames which make the frames stay instead of removing them to display the next one. This is an example of the APNG result when I have cumulative enabled when extracting the frames of the gif then recombine them using UPNG. https://cdn.discordapp.com/attachments/626649734953566218/814236015316434954/1614199393560.png

And here's another if I disable cumulative when extracting the frames then recombine using UPNG. The stacking isn't as bad but it still is keeping data from previous frames. https://cdn.discordapp.com/attachments/626649734953566218/814238946128953354/1614200092424.png

The original gif I used for the above examples is https://media3.giphy.com/media/Wwe6DNWWOvfBbr9Gbc/giphy.gif.

All of the png frames that were extracted from gif-frames look fine when I output them one by one before combining them into a apng image which the only other thing it can be is UPNG.

The result is fine if the image doesn't have a transparent background around the moving parts. https://cdn.discordapp.com/attachments/626649734953566218/814229966102331427/1614197951358.png