Hi @Vahid-Taheri, thanks for pointing this out! world-calendars is a package we created specifically for plotly.js, though apparently it's still housed in my personal GH account (@gvwilson FYI I'm happy to keep it or transfer to the plotly org at your discretion). It hasn't been updated in 8 years because nobody has reported any issues with it during that time, until now. Originally the project was codegen'd from this JQuery plugin by @kbwood, which I see has had some updates since we pulled it in 2016, so perhaps your issue has already been fixed upstream and we should just rebuild and pull it through? Alternatively we could break that link and inline the code in plotly.js, or we could move the codegen into plotly.js - though there are apparently a few non-plotly.js dependents on world-calendars so the best overall would be to fix it in place.

FYI back in 2016 when we pulled the original I apparently didn't find it published on NPM so I copied the source code into my repo. It now apparently is published: https://www.npmjs.com/package/kbw-calendars - but I only see up to v2.1.0 published there while the latest in https://github.com/kbwood/calendars is v2.2.0, so I guess best is to still copy in the source code. Also note that in v2.1.0 kbwood reorganized the repo, so there will likely be a bunch of work to get the codegen working again.

Hmm I was optimistic that the new upstream version would fix the issue you identified @Vahid-Taheri, especially since the latest version over there is just two months old (suspiciously close to the date this discrepancy occurs!) but it seems the leapYear code has not changed since then. Here's the current kbwood code for Persian leap year and the corresponding world-calendars code

@Vahid-Taheri is that the same code you were trying to edit? Do you have a proposed update that would give the correct leap years in all cases? Or a reference you can point us to for precisely how to decide which years are leap years?

Ideally I guess this means we should open a PR upstream to fix the bug there before we update world-calendars.

The Persian calendar was correct as is (according to https://www.iranchamber.com/calendar/converter/iranian_calendar_converter.php and https://www.parstimes.com/persian/calendar/). I have added a new "iranian" calendar to provide one that matches the alternative version with 1403 being a leap year (http://www.time.ir/).

Hi @alexcjohnson, thanks for your early answer. In Jalali calendar, often leap years repeats every 4 years. 1395 was leap year, 1399 is leap year, 1403 is leap year too. By this pattern the next leap year should be 1407, but it is not ! because of that scientists !! 🙄😂 The next leap year is 1408. If you want to read more, this link is a good source.

About algorithms, I found two algorithms that cover this issue.
1- ngb-calendar-persian
2- Persian-leap npm package

Thank you @kbwood - and I don't think we've corresponded before but let me say thank you for creating and maintaining your calendar plugin, that's been the basis of Plotly's international calendar support for nearly a decade now!

It does look like your leap year logic in iranian.js matches that in ng2-datepicker-jalali. The persian-leap package uses a bit different logic so it's a bit hard to match up but it also has two different calculations available, presumably corresponding to the distinction between your Persian and Iranian calendars. Do we know if both of these calendars are in use, and if so in what contexts? We can certainly follow your lead and include both, but because they're so similar it would be useful to give users clear guidance on their usage. I see on your docs that the Iranian calendar is "also known as Solar Hijri calendar" whereas the Persian is "also known as Jalali calendar" but the implication of this discussion is that @Vahid-Taheri considers your Iranian/Solar Hijri to be the Jalali calendar so I gather there's still some confusion.

@alexcjohnson, both are the same (or maybe a little different). We mostly use Jalali calendar.
moment-jalaali and date-fns-jalali are two common npm packages we use, and both of them are trustworthy sources. Their leap year implementation is the same as the algorithms we checked before.

Thank you @Vahid-Taheri for raising this issue. And thank you to everyone else for addressing it. @kbwood, where and how can we access the new "iranian" calendar that you have added? I can't seem to find it in the plotly codebase.
Also I noticed there is a "persian" calendar option. What is the difference between that and the "jalali" option?

@hmanz we (Plotly) will need to rebuild using the new version of @kbwood's calendar code in order to get the new iranian calendar. And again that may take some time due to the altered structure so bear with us.

But I'm still unclear on the usage of these calendars and how we can help our users to pick the correct one for their needs. @Vahid-Taheri what do you mean by "mostly use Jalali"? Are there specific cases where the other one is used?

@alexcjohnson and @hmanz, Jalali, Persian, Iranian, and Solar Hijri are all the same, and in global convention and language, we use the Jalali name for it. Still, in the native language, we call it Solar Hijri (هجری شمسی). This article may help you in this subject.

It was strange for me to see both in world-calendar package. I think it's better to fix one and refer another to that to keep safe usage for users who are using each one.

The new calendar is available in my Calendars project. I'm don't fully understand the difference between the two calendars but they correspond to two different implementations as mentioned in my previous post.

Hi everyone - so is the best solution here for plotly.js to switch to @kbwood's project (https://github.com/kbwood/calendars) rather than continuing with @alexcjohnson's (originally https://github.com/alexcjohnson/world-calendars, but I'm in the process of moving it to https://github.com/plotly/world-calendars)? Fewer packages => less confusion ?

It isn't really possible for us to use kbwood/calendars directly, as it's structured as a jQuery plugin. But world-calendars is codegen'd from kbwood/calendars, we just have to rerun the codegen on the new version, and make any updates necessary for that to work. And perhaps also find a way to either pull the codegen input directly from kbwood/calendars or automate copying it into the world-calendars repo, I originally just copied the relevant files manually.

I'm kind of in the same boat as @kbwood in that I don't really understand the distinction between persian and iranian, it kind of sounds like only iranian is in common use but perhaps we keep both and just add an explanatory note to our docs for both, something like "persian and iranian differ only in leap year algorithm. iranian is the calendar in current common use in Iran."?

I have another repository for the world calendars that removes the jQuery dependency: https://github.com/kbwood/world-calendars. It is written in TypeScript however.

Oh that's cool, thanks for pointing that out! We should be able to use kbwood/world-calendars directly rather than doing codegen from your jQuery package. I'm not sure if plotly.js has any TypeScript dependencies right now but that should not be a blocker.

I'm curious what you plan for these projects going forward. Clearly it's not ideal to be maintaining two parallel codebases, perhaps there's a route to calendars becoming a thin jQuery wrapper around world-calendars?