Algorithm 为什么日历转换库围绕着朱利安日展开？

我目前正在编写一些php代码，将日期从公历转换为希伯来历。查看php日历函数，我发现它有一些函数可以将格里高利日转换为朱利安日，将朱利安日转换为希伯来语。然而，我找不到直接将格里高利语转换成希伯来语的功能

出于好奇，我想看看是否可以直接转换。在研究这个问题时，我发现将日期转换为朱利安日，然后再转换为所需的日历系统似乎是标准的

我在以下几个库中发现了这一点： http://www.fourmilab.ch/documents/calendar/calendar.js

在这里的论坛帖子上提到：

困扰我的是为什么！这是由某个团体决定的标准吗？历史上就是这样吗

---

提出直接转换日期的算法不是更有效吗？或者反过来说，是什么让朱利安日如此高效呢？

如果你想在

n

不同的日历之间进行转换，并且实现了从任何一种格式到任何其他格式的算法，那么你需要

n^2-n

转换算法。但是，如果编写算法将任何日历格式转换为一种基准日历格式，然后编写算法将基准格式转换为任何其他格式，则只需编写

2（n-1）

算法

这些日历格式都代表同一件事，时间。表示时间的最基本方式是表示自某个参考点以来经过的时间量，因此作为基线格式最有意义。这就是自公元前4713年1月1日格林威治正午以来的天数

---

您可能会认为，从一种格式转换为朱利安日期，然后再转换为另一种格式会比较慢，但是任何专门的转换算法基本上都会将输入日期转换为某种中立的中间日期表示形式，然后将其转换为所需的日历格式。然而，由于Julian Date是一种简单的单数字格式，这实际上等同于转换为Julian Date，然后再转换为其他格式，因此性能增益可以忽略不计。此外，日历转换可能不是任何应用程序性能的瓶颈，因此从日历转换中挤出尽可能多的性能可能不会很好地利用任何人的时间。

我知道这可能不是瓶颈，只是看起来像是使用了一个普通的“中间人”在几个不同的系统之间是一个奇怪的解决方案。现在它确实更有意义了，特别是从维护的角度来看，几乎任何类型的转换都将使用某种“中间人”。假设您正在将图像从JPEG转换为PNG。您不会将JPEG数据直接转换为PNG。您将把JPEG解压缩为位图，以获得每个像素的颜色值，然后将其压缩为PNG格式。实现从JPEG压缩到PNG压缩的直接转换将非常困难。