Euclid wasn't wrong: once given the axioms, everything follows with absolute certainty. Change the axioms, if you want to change the behaviors.

Calendars may differ from each others under at least three respects, as far as I can see. It is uncommon that all these three differences would be present at once, when comparing two calendars. Yet, a good script should be able, as far as I can envision what a good script should be in this instance, to account for all the ensuing scenarios, namely including the worst case: that of all the differences being present at once.
These differences as they are presumed in this script can be:

• The amount of days composing what is considered a year differ in the two compared calendars - that is, one calendar may include more days.
  This is not a likely case though.
• The beginning of the year is set, on the compared calendars, onto two different offsets.
  This is a most common case.
• The grouping of the year days into subsections (so called months) may not divide the years in fragments of identical lengths or into identical sequences.
  This is possible, and must be accounted for.

Whatever the case, there is an element that must be understood.
When we speak of finding out a date equivalent to another throughout two different calendars, no such equivalence could be spot at all if the two concurring calendars wouldn't be referring implicitly to a third entity, external to both, in relation to which they differ.

If it weren't so, and calendar A would start at day X, whereas calendar B would start at day Y, there would be no way to say: day Y coincides with day X, if there wouldn't have been another external and stable entity accordingly to which both pose.
Consider a day. A day is not a mere mathematical entity. A day is the time that goes between two dawns (or the time from high noon to high noon). If the sun wouldn't have been there as common point of reference for both calendars, no conversion would be possible.

Consider two runners. A runner runs one mile, the other one kilometer. If you would have had no previous idea about how long a mile and a kilometer are, you'd have to put both runners on the ground, make them run, and then when they both stop compare the ground they have run. The ground is their "third" entity.

For time, it is recurring events what makes the common milestones, rather than the traversed space.
Thus we can have a Gregorian Calendar that starts the first of January. But what is the first of January? You have to express it as a function of the rotation of the earth around the sun that pinpoints a position attained during such rotation, or it would just be an empty and meaningless expression.
Analogously, the Zodiacal Calendar starts on what in the Gregorian Calendar would be called the 21st of March. But for the Zodiacal Calendar, that date is not the 21st of March (it is such only for the Gregorian Calendar), it is rather the first day of the year. How does the Zodiacal Calendar derives it? From that external event named the Spring Equinox:

«The Sun is at its lowest path in the sky on the Winter Solstice. After that day the Sun follows a higher and higher path through the sky each day until it is in the sky for exactly 12 hours.
On the Spring Equinox the Sun rises exactly in the east travels through the sky for 12 hours and sets exactly in the west.
On the Equinox this is the motion of the Sun through the sky for everyone on earth. Every place on earth experiences a 12 hours day twice a year on the Spring and Fall Equinox.»

[source]

So the Equinox is when light and dark last exactly the same amount of time within the day: March 21 is the first time of the two times a year that the day meets this requirement.

If you would have a planet spinning around the star named Polaris Australis, we could say that its year is the time it gets to reach one same position (in respect to Polaris Australis) during its rotation around it.
That year would last differently than the year of planet Earth while the latter runs around the Sun: because both orbits and speeds differ.
Also, it is possible that its days last longer or less than a earth's day (say that a day is, defining it more generically than the time between two dawns, the time between two identical positions in respect to the planet's rotation onto its own axis).

If the Earth takes 365 days for a year and 24 hours for a day, and the other planet takes say 800 days (full revolution around the star) and each day of the latter planet is composed of 8 hours (full rotation of the planet/s around its own axis), what you are doing is to describe the other planet through a convention that imposes to it some of the Earth's units of measure (for instance, the hour).
What this implicitly means is: one planet is being used as the criterion of measurement for the other.
And so calendars do too.

What we call a year can be generalized as the amount of rotations around its own axis that a planet does before reaching again one same position in its rotation around a star.
If these days (=rotation on axis) that populate a year (=rotation around a star) have different durations for two different planets (ie the two planets take two different amounts of time to carry out each its own complete rotation each around its own axis: which is its "day"), then what must be calculated for conversion purposes is how many times (rounds) each rotation on the axis of one planet (arguably the faster) is included within one full rotation of the other.
This emancipates from considering the day as a sequence of hours, because the day becomes now what it is, a function not of the hours but of definitive spatially localized coordinates.

If in the time planet A rotates once on its axis, planet B rotates 3 times on its own axis, this means that days are compared as follows:
Planet A:[1]     [2]     [3]      = 3 days
Planet B:[1,2,3] [4,5,6] [7,8,9]  = 9 days The operations required for the conversions from a day in B into a day in A is to calculate first the ratio between 1 day in A and the amount of rotations on the axis performed in the same time by B:
A/B = 1/3 = 0.33333333
Then, if you want to know to what day in A corresponds, say, the 5th day in B:
B * (A/B) = A = 5*0.33333333 = 1.6666666
which latter number means that the 5th day of B corresponds to having completed one full day of A (because 1.6666666 is bigger than just 1), and to have thus entered the second day of A by a 0.6666666 fraction of it considered as a unit 1. Conversely to convert a day in A into a day in B, if still A/B = 1/3 = 0.33333333, then:
A/B * 1/A = 1/B; => B = 1/(A/B * 1/A)
So, applying it, if we want to know to which day in B the 2nd day of A corresponds we have:
1/(0.33333333 * 0.5) = 6
which is the uppermost limit of a day in B for the day 2 in A.
To get also the lowermost limit:
(1/(A/B * 1/A)) - ((1/(A/B))-1)
namely for the previous example:
6 - ((1/0.33333333)-1);
6-(3-1)=4 However the conclusion I attained is that we shall consider all days as being Planet Earth's days, namely all the calendars as calendars made to calculate time on our planet where every day, in every calendar, is from noon to noon (or from dawn to dawn, being the elapsed time still the same). We will see this suffices.

Let's start saying that the first parameters our script shall want, is the lengths in days of the two calendars.
As I said and in order to make the script as flexible as possible, I shall account also for the possibility that the calendars will differ in the amount of days each contains.
So, let's imagine two simplified calendars one with 9 days only and one with 4 days only:
calendar A: 123456789
calendar B: 1234

How do we convert?
At first I thought of producing arrays. Because it is apparent that what we need to do to yield a comparison table would be to have column equivalences in the shape of:
calendar A: 123456789
calendar B: 123412341

As you may notice, in order to saturate the capacity of calendar A, calendar B has to repeat itself many times till the capacity is filled.
Note also that these repetitions leave a trail (a 1) that is not a full set like the preceding 1234 because 9 (the days in calendar A) is not evenly divided by 4 (the days in calendar B).

However, producing arrays is not the optimal solution. It is a decent and rational way to do the thing, and maybe even a clean one, and also what I set out with at first, and yet it implies a computational task that can be spared. In fact, remembering my previous essay about UNIVERSAL CAST: CAST AND RECAST NUMBERS, CHARS OR STRINGS INTO CUSTOM INTERVALS OF VALUES, these comparisons can be achieved by mere primitive mathematical operations such as the division.
An array, that's a multiplication in disguise.

From Calendar A to Calendar B

Here is how I can proceed to convert a date from calendar A (say the 7th day) into calendar B:
calendar A: 123456789
calendar B: 123412341

1. Get the given day of the other calendar (A, and the example day is the 7th).
   Divide this number by the amount of days of the shorter calendar:
   7/4=1.75
2. Of the latter yielded number, get its non decimal part: this says how many years have elapsed for calendar B (in our case, being that 1, means that one year of calendar B is over).
   Get its decimal part (0.75) and multiply it by the days in the year (4):
   0.75*4 = 3
   If there is no decimal part, return the days in the year.
   Otherwise, return the result of the last calculation (3) as the day, and the non decimal part (less 1 if there was no decimal) to signify the year of B.

From Calendar B to Calendar A

Here is how I can proceed to convert a date from calendar B (say the 3rd day of the second year) into calendar A:
calendar A: 123456789
calendar B: 123412341

1. Multiply the year (1, because the count starts with year zero) by the days present in such year (of B, namely 4):
   1*4=4
   If the calendars are of the same amount of days, the year is considered number zero.
2. Return such number plus the passed day (4+3=7).
   Ps, to keep consistency with the structure returned in the previous conversion (convert a date from calendar A into a date of calendar B), return also the year (1).

The good thing with this procedure, is that we have used no arrays. Besides, it works smoothly also if the years are both containing the same amount of days, as it is by far the commonest case: in this last instance a bit of unnecessary calculations are carried out, but it's utterly negligible when all we have to ask to a processor is to make a couple of divisions, with which we can account for more complicated cases too.

However there is now a difficulty that overlaps: imagine that one of those years whose days you have thus compared, are fictional days: that is, imagine that (say) each day in calendar B was actually a day in respect to calendar A, but was a set of, say, 2.3 (2 point 3) days for calendar B: that is, in the time the planet of calendar A makes a full rotation, the other planet in calendar B actually makes 2.3

If so, what you know is that you have grouped the days of calendar B into superdays which are actually each a disguised set of 2.3 rotations.
So what you called in calendar B day 1 was actually 2.3 days, and so was day 2 and so on...

When you convert from A to B, and you want to account for this too, it means that the day in A (say the 7th) which returns the number 3 in the second year of calendar B, is actually a set of 2.3 days, preceded by (1year*4)+3 sets of 2.3 days.
So:
((1*4)+3 ) * 2.3 = 16.1th day

If you want to convert from B to A, and you want to convert the 16.1 day, you know that in order to group it in a way fit to meet one single rotation of the other year you have to divide by 2.3:
16.1 / 2.3 = 7
Since you also know that such 7th day is in the second year and that a year is of 4 days:
7/4=1.75
which means in the non decimal part that one year has passed.
Get its decimal part 0.75 and multiply it by the length of a year 4:
0.75*4=3
which means the 16.1 day of a two years span of calendar B, is day 3 (in the second year, of course).

What have we concluded with this? That a good script that meets the requirements of all calendars does not need to account for rotations, but only for figmental rotation sets. Once returned the results, you can manipulate them with a few additional computations as the ones above, if you want to disembody a fictional set from its fiction.
Thus, it shall be enough for me to proceed, or so it seems to me, with a script where all days are the same (fictional) length.

In the script, you'll obviously have to pass two amounts of days for each of the two calendars to be compared. This makes sense. Well, the first amount of days passed, shall be supposed to be the one that performs as unit measure of the other, and the second passed as the only one that might also be the fictional one in the sense previously expounded:
function(365, 200); //pseudo code

It is well possible that, given two calendars A and B, calendar B considers the beginning of the year a date that, within calendar A, matches a day that for A is not the beginning of the year.
Also in this case, as stated in the closing remark of the previous chapter, the amount of days of the calendar whose beginning of the day undergoes a shift in respect of the other, has to be the second amount of days among the two amounts of days passed to the script:
function(365, 365);

The expression above (although pseudo code, and still incomplete) already presumes that if there is going to be a calendar whose beginning of the year has to be expressed in function of the other, this is the one referred by the second parameter 365.

So let's imagine two years of equal length (for visual purposes, both of 9 days, ok?):
calendar A: 123456789
calendar B: 123456789

If calendar B's beginning of the year is settled on its 6th day, it means that all that is from 6 up, has to be put before what is before it in order to preserve the equivalences between the two calendars:
calendar A: 123456789
calendar B: 678912345

This shift, already sets the new conversion table with the given equivalences.
Of course, once again rather than doing it building an actual table via arrays, I want to achieve this by mere mathematical operations.

However, let's write down also a shift example onto a calendar of different years days:
calendar A: 123456789
calendar B: 123412341
which if the offset is on day 3 in A could become:
calendar A: 123456789
calendar B: 341234123

The calculations will be performed on the results returned by the operations performed in the previous chapter; namely firstly I will calculate as if there would have been no shift, and secondly on those results I will apply the shift. This seems the nicer way to do it - at any rate for this application.

In this fashion, you know that whatever conversion has been produced at this stage pretending there is no shift, what will be returned and consigned to further elaboration, shall be a set of two numbers: the converted day, plus another number signifying the year if the two calendars were of different lengths.

What we have now to do, is to rearrange this result in order to accommodate the year shift:

• From the returned set of two numbers yielded by the previous calculations (that is, remember: the ones that converted the dates pretending there was no year shift in place yet), store the first number (we shall call it just: returned).
• Store the OFFSET. The offset is the day number in calendar B that is considered as the beginning of the year in respect to calendar A.
• Calculate a variable we shall call K1 (K for konstant 1): this shall be OFFSET less 1 (this tells the amount of days that were after the offset day)
• Calculate a variable we shall call K2 (K for konstant 2): this shall be the amount of overall days present in the calendar that undergoes the shift (and if it's present a calendar which has less days, then it must be this latter) less K2 (this tells the amount of days that were before the offset day).
• If you are converting A into B, wonder: is returned higher than K2?
  A: 123456789
B: 123456789 (as returned unshifted)
B: 456789123 (as shifted. Offset=4, K1=3, K2=9-3=6)
  Return returned - K2
  
  If you are converting B into A, wonder: Is returned higher or equal to OFFSET?
  B: 123456789
A: 123456789 (as returned unshifted)
B: 456789123 (as shifted. Offset=4, K1=3, K2=9-3=6)
  Return returned - K1 (note that there is an additional interesting comment in the codes about a tricky issue with this operation that made me "waste" over a day on it; the mentioned comment is placed at about the end of the class method named shift)
• If you are converting A into B, wonder: is returned lower or equal than K2?
  A: 123456789
B: 123456789 (as returned unshifted)
B: 456789123 (as shifted. Offset=4, K1=3, K2=9-3=6)
  Return returned + K1
  
  If you are converting B into A, wonder: is returned lower than OFFSET?
  B: 123456789
A: 123456789 (as returned unshifted)
B: 456789123 (as shifted. Offset=4, K1=3, K2=9-3=6)
  Return returned + K2

TEST IT

calendar A days: calendar B days: offset: convert day: [ from A to B, from B to A ] year:

What is necessary to understand before we deal with the months, is the actual way the operations of conversions you may have used in the test form above can be employed.

Firstly, bear in mind the differences between a cardinal and an ordinal number.
A cardinal number can be defined, grossly, as just what a number is (one, six, eight...) regardless of any other consideration, whereas an ordinal version of the same numbers would be: the first, the sixth, the eight number, that is: an ordinal number tells a rank position, tells what the same number is with regard to a sequence.

«cardinal number : the number of elements in a mathematical set; denotes a quantity but not the order.»
[source]

Conversely:

«ordinal number: the number designating place in an ordered sequence.»
[source]

Now, let's see again the two trivial calendars I used as example, A and B with an offset shift in B (a necessary complication, otherwise no conversion issue would ever raise in order to translate from identical calendars):
A: 123456789
B: 456789123

As long as from calendar A you pick a day, say the 5th day of A, its corresponding entry in calendar B, namely 8 (which would be the returned value of a conversion of number 5 from A into B), is of no great use.

In fact what you want to know when you perform such a comparison is: to which ordinal number the day X picked from A corresponds to, within B considered as an ordered sequence?

Therefore this implies something slightly counter intuitive: in fact it means that the right way to use these scripts is to get the number X from A and convert it not (not) from A into B (despite you picked it exactly from A!), but from... B into A, by picking the same number X from B (and not from A) although X was originally chosen from the domain of A!

In fact, considering number 5 picked from A, let's look for it in B and find its equivalence in A:
A: 123456789
B: 456789123
This tells: 2, which means: in calendar B the number X (=5) in calendar A is... the 2nd in calendar B's order!
This is what you really meant to know, and implies that the way to use this script is (so to say) the other way round that one might have at first guessed. If this is clear to you, we can now proceed to solve the last difficulties namely those related to the months.

Months are actually nearly arbitrary groupings of the flushing sequence of the days in a year, in sub sequences; each of these sub sequences (months) represents an ordered set of its own: and when you say it is the 4th day of February, you are just calling with another name the 35th day of the year (because before February there are January's 31 days, and so 31 + 4 = 35).

I think that at this stage you can have at least a solid intuition of what may be going to happen next.
In order to translate a year's day (that is, a day expressed in its order within a year rather than within a month) into a month's day, all we need is to know in which sequences these month's groupings occur for the given calendar. So, under a programming point of view, what we need is arguably an array that, for instance for a familiar Gregorian calendar, says:
[31 (January...), 28(or 29), 31, 30, 31, 30(May...), 31, 31, 30, 31, 30, 31]

It would be rather simple, now, to derive from a month day expression like, say, May 18, its corresponding year day (which is the format you saw used in this script): you just have to sum all the numbers in that array before May, stop short of May, and then add 18.

Of course, there is no other way but to provide the months divisions by hard coding them. In fact months are whimsical entities, and the fact they are arranged that way should not conceal from your eyes that nothing would have prevented to use occasionally and for instance also months of 32 days compensated by other of 29. Or maybe that the mere sequence of alternating 30 and 31 could have been arranged differently.

So, months cannot be deduced (in programming terms: calculated). Since there is a patent degree of subjectivity in them, it is necessitated that for any given calendar months must be known beforehand, which in programming terms means: they must be hard coded, they must be plainly stated.

In the next section you will have the codes and the instructions about how to use the script and manage months.

Before I explain to you how to initialize the script, what its arguments are and how to use its methods, its belated code: The initialization of the class could look like the following, and its arguments shall be promptly explained (foo is a placeholder for whatever variable name you may prefer):

var foo = new calendars(Number, Number, Number, Array, Array, Array, Array);

The arguments are in the following order:

1. A: a Number. Is the amount of days in one of the two calendars upon which you want to perform the conversions.
2. B: a Number. Is the amount of days in one of the two calendars upon which you want to perform the conversions.
   However, it is paramount to keep in mind that if a calendar has to have an offset shift, it must be the one referred by this argument, and not by the previous one. Also if it is a calendar with less days than the other, this shorter calendar must be the one passed as this argument.
   This caveat applies insofar as we have said that one calendar must perform as criterion of the other, and such is the one passed as the first parameter and if this latter has to perform such a role, it must be a calendar that spans beyond the capabilities of the other in order to perform as an exhaustive criterion of comparison.
3. offsetB: a Number. Defaults to 1, if passed as zero still defaults to 1. If it's another number, it shall mean that the calendar passed as parameter named B shall have to undergo a shift which will move this offset entry number to the beginning of it.
   If you have perused a bit the discussion above, you know what this means.
4. monthsA: an Array of numbers. Defaults to an array of month numbers (that is, how many days per each month) that follow the standard Gregorian Calendar (this default will set the default year to the current date, and arrange the days of February considering the possibility of a leap year) and that are the months of calendar A:
   
   [31, ((isLeap)?28:29), 31, 30, 31, 30, 31, 31, 30, 31, 30, 31];
5. monthsB: an Array of numbers. Defaults to an array of month numbers (that is, how many days per each month) that follow the standard Gregorian Calendar (this default will set the default year to the current date, and arrange the days of February considering the possibility of a leap year) and that are the months of calendar B:
   
   [31, ((isLeap)?28:29), 31, 30, 31, 30, 31, 31, 30, 31, 30, 31];
6. monthsANames: an Array of strings. Defaults to an array of month names that follow the standard Gregorian Calendar and that are the months (names) of calendar A:
   
   ["January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December"];
7. monthsBNames: an Array of strings. Defaults to an array of month names that follow the standard Gregorian Calendar and that are the months (names) of calendar A:
   
   ["January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December"];

Here are the methods that you may use:

• foo.getDays(Number, Number, Number)
  Given a month day (first parameter), and a month number (second parameter, whereas keep in mind that zero counts: months start counting the first month of the year as zero. However if you pass this second parameter as a string, which shall be treated in case insensitive mode, the method will see if it finds in the class a month with such name and convert it in its corresponding number), and given a third parameter which is still a number (if zero, it shall mean the operations shall have to be performed on calendar A, if 1 that they have to be performed on calendar B), this method will return, for the given calendar, a number representing what year number day such a date represents.
  
  For instance, on a Gregorian Calendar a date like [2, 2, 0] would mean: [2, March, calendarA] and would return the days of january (31) plus the days of february (28 or 29 if leap year; say it isn't) plus 2 (March) namely will return: 61.
  
  Note that no validation shall be performed in case you mistakenly insert a day that exceeds the corresponding month or a month number (or name...) that does not exist (this keeps the computational horizon of the class a bit wider, in case one wants to use it for computational experiments).
  foo.getDays(, , );  
• foo.convert(Number, Number, Number, Number)
  This is the actual engine of the script. You can see it in action in the test form set up a few chapters above.
  Its arguments are as follows:
  1. A number representing the year days of the calendar (A or B, we shall see soon which) upon which you want to run the script namely find its equivalence into the other calendar.
     
     Since this parameter must be year days, it won't be unusual to find out you might even pass as such parameters a call to the class method explained just above namely to getDays() in case you have a date in month day format and you want to transpose it instantly into an year day format.
  2. A number. If zero, it shall mean that for the year day previously passed, you want to find such day within calendar A and transpose it into calendar B.
     If passed as number one1, the same operation shall be applied the other way round: from calendar B into calendar A.
     
     It is very likely that most of the times, actually, you shall have to pass this parameter as 1.
  3. A number from zero onward. This is a feature that shall have an influence only if you are dealing with calendar B and it's shorter than calendar A: if it is shorter, it means that there are recurrences of year days within calendar B that are such because, being the calendar smaller than A, it is included within the scope of A multiple times: which means, multiple years (of B). Such multiple years, if you have read some of the above, will be reflected via mathematical operations that ideally repeat the set of the year days of B until they fill the capacity of the days available in A.
     So in such case, it is possible one wants to derive a correspondence in A not for the first year round of B, but for any of the next ones. See some possible recurrences:
     
     A: 123456789
B: 123123123
     
     To mean "within the first year" pass zero, and onward from there.
  4. A number, and if not passed it will be replaced by the offset passed upon initialization of the class instance (or to its default which is 1): it must be the offset shift you want to apply to calendar B.
     Actually, you can altogether forget about this argument if you want just to rely upon the offset passed upon initialization.
  The method shall return an array, whose entries are as follows:
  0. The converted year day.
  1. The day as it would have been converted if no offset was in place (so, it could also be a repetition)
  2. The variable named K2 discussed earlier namely the amount of numbers that are in the offset that has been shifted at the beginning of B.
  3. The year argument, if passed (for mere convenience, I return that too).
  4. Another... array! This is a call on getDate() namely it will transform the year day into its set of:
     [0] = month day
     [1] = month number
     [2] = month name
• foo.getDate(Number, Number)
  Do not mistake this with getDays.
  This method makes the viceversa of getDays namely given two parameters (the first a year day, the second either zero to signify grab the class properties associated with calendar A, or 1 to mean grab the class properties associated with calendar B), returns for such year day an array of three entries that transposed it as:
  [0] = month day
  [1] = month number
  [2] = month name
  foo.getDate(, );  

As a bonus example or case study, I shall now convert a standard Gregorian Calendar into a Zodiacal calendar, whose differences from a Gregorian calendar are that it starts on March 21 (Spring Equinox), and its months are arranged differently and named after the Zodiacal signs. March 21 in zodiacal terms is the first day of the Aries month.

However, if I run the case study and I apply to B an offset equal to 80 (March 21 expressed in year days of A), what I find is that the script reports that the first day of the Aries month in calendar B coincides with October 14 in calendar A. It should not, because the exact correspondence in calendar A should have been March 21, not October 14.

The script here escaped my own understanding, but at the same time I was so sure its inner logics were convincing, that I applied getDays(21, 'October', 0) to see returned this number: 287, which expresses the amount of year days that correspond to the date October 14.
Using as offset this number 287, and not 80, we get a perfect equivalences table.
How can I tell this? By the fact that to the date first day of the Aries month of B, corresponds March 21 in calendar A. This, must be the proper table. Tweaking with the script, we can get what we want. It has the power to do the thing. The same considerations made for the calendar conversions above, can be made for the conversion with the French Revolutionary Calendar, which should start with September 22 (1st Vendémiaire, in the French Revolutionary Calendar naming), and has 12 months of 30 days plus 5 or 6 days (if it's leap year), each of them with beautiful month names (the trailing 5 or 6 days are called Sans Culottides).

The same appartent issue reported with the previous calendar applied here too: 1st Vendémiaire (September 22, namely 265 year days) in B did not coincide with September 22 in A when applying 265 as offset parameter, but with April 12 (namely 102 year says). Using 102 as offset, you get a perfect equivalences table, whose correctness you can also compare and double check at your ease with the University of California at Los Angeles (UCLA) converter for the French Revolutionary Calendar.

Of course, if you have a better grasping of this "issue" (in between quotes, because with this trivial workaround it woks just fine!), or if you just want to reassure me it's just one of the potentialities of a script developed in this flexible way, feel free to email me.