Why do calendar conversion libraries revolve around Julian days?

Question

I am currently writing php code to convert dates from the Gregorian calendar to a Hebrew calendar. Looking at the functions of the php calendar, I found that it has functions for converting from Gregorian to Julian days and Julian days to Hebrew. However, there is no function that I could find to directly convert from Gregorian to Hebrew.

Out of curiosity, I wanted to see if a direct conversion is possible. Although, while researching this, I found that it seems standard to convert dates to Julian days, and then to the correct calendar system.

I found this in several libraries, such as: http://www.php.net/manual/en/ref.calendar.php http://www.fourmilab.ch/documents/calendar/calendar.js

and is mentioned here on the forum: http://www.physicsforums.com/showthread.php?t=173119

What bothers me, why! Is this a standard adopted by some group? Is this done historically?

Wouldn't it be more efficient to come up with direct date conversion algorithms? or, conversely, what makes Julian days so effective?

Answer 1

If you want to convert between n different calendars, and you have implemented algorithms for switching from any format to any other format, you will need n^2 - n conversion algorithms. However, if instead you write algorithms to convert any calendar format into one basic calendar format, and then write algorithms to convert from a basic format to any other format, you only need to write algorithms 2(n-1) .

These calendar formats represent the same thing, time. The easiest way to represent time is the amount of time that has elapsed from a certain reference point, so that it makes the most sense as a base format. This is exactly what Julian Date is the number of days from January 1, 4713 BC. Greenwich afternoon.

You might think that it would be slower to convert from one format to Julian Date and then to another format, however, any specialized conversion algorithm will, in fact, take an input date, convert it to some neutral transition between the date representation and then convert it to the desired calendar format. However, since Julian Date is a simple single-number format, it is actually the same as converting to Julian Date and then converting to some other format, so the performance gain will be negligible. In addition, calendar conversions are probably not a bottleneck for any application performance, so compressing the most possible performance of them is probably not very useful at any time.