4

I'm currently writing some php code to convert dates from the Gregorian Calendar to the Hebrew Calendar. Looking at the php calendar functions, I found that it has functions to convert from Gregorian to Julian days and Julian days to Hebrew. However, there is no function I could find to directly convert from Gregorian to Hebrew.

Out of curiousity, I wanted to see if a direct conversion was possible. While researching this though, I found that it seems to be standard to convert dates to Julian days, and then to the desired calendar system.

I found this in a few libraries like: http://www.php.net/manual/en/ref.calendar.php http://www.fourmilab.ch/documents/calendar/calendar.js

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

Whats bugging me is why! Is it a standard decided on by some group? Is it just done this way historically?

Wouldn't it be more efficient to come up with algorithms to directly convert dates? or conversely, what makes Julian days so efficient?

Kevin Engle
  • 55
  • 3

1 Answers1

7

If you want to convert between n different calendars and you implemented algorithms to go from any one format to any other format, you would need n^2 - n conversion algorithms. However if instead wrote algorithms to convert any calendar format to one baseline calendar format and then wrote algorithms to convert from the baseline format to any other format you only need to write 2(n-1) algorithms.

These calendar formats are all representing the same thing, time. The most basic way to represent a time is as the amount of time elapsed since some reference point, so that makes the most sense as a baseline format. This is exactly what Julian Date is, the number of days since January 1, 4713 BC Greenwich noon.

You might think that it would be slower converting from one format to Julian Date then to another format, however any specialized conversion algorithm is essentially going to take the input date, convert it to some neutral go between date representation and then convert that to the desired calendar format. However since Julian Date is a simple single number format this is effectively the same as converting to Julian Date and then converting to some other format so the performance gain would be negligible. Also calendar conversions are probably not the bottleneck of any application's performance so squeezing the most possible performance out of them is probably not a good use of anyone's time.

David Brown
  • 13,336
  • 4
  • 38
  • 55
  • I understand that it probably wouldn't be a bottleneck, it just seemed like using a common "middle man" between several different systems was a weird solution. It does make more sense now, especially from a maintenance standpoint – Kevin Engle Dec 22 '11 at 03:44
  • 3
    Almost any type of conversion is going to use some kind of "middle man". Say you are converting an image from JPEG to PNG. You aren't going to take the JPEG data and directly convert it to PNG. You're going decompress the JPEG into a bitmap to get the color values of each pixel and then compress that to the PNG format. Coming up with a direct transformation from JPEG compression to PNG compression would be very difficult. – David Brown Dec 22 '11 at 03:55