algorithm - 为什么日历转换库围绕儒略日?

标签 algorithm calendar julian-date

我目前正在编写一些 php 代码以将日期从公历转换为希伯来历。查看 php calendar 函数,我发现它具有将 Gregorian 转换为 Julian days 以及将 Julian days 转换为 Hebrew 的函数。但是,我找不到直接从公历转换为希伯来语的函数。

出于好奇,我想看看是否可以直接转换。不过,在对此进行研究时,我发现将日期转换为儒略日,然后再转换为所需的日历系统似乎是标准做法。

我在一些库中找到了它,例如: http://www.php.net/manual/en/ref.calendar.php http://www.fourmilab.ch/documents/calendar/calendar.js

并在此处的论坛帖子中提到: http://www.physicsforums.com/showthread.php?t=173119

困扰我的是为什么!这是某个团体决定的标准吗?历史上就是这么干的吗?

想出算法直接转换日期不是更高效吗?或者相反,是什么让 Julian days 如此高效?

最佳答案

如果你想在 n 不同的日历之间进行转换,并且你实现了从任何一种格式到任何其他格式的算法,你将需要 n^2 - n 转换算法。但是,如果改为编写算法将任何日历格式转换为一种基线日历格式,然后编写算法将基线格式转换为任何其他格式,则您只需要编写 2(n-1) 算法。

这些日历格式都代表同一事物,即时间。表示时间的最基本方法是从某个引用点开始耗时量,因此作为基线格式最有意义。这正是Julian Date是,自公元前 4713 年 1 月 1 日格林威治中午以来的天数。

您可能认为从一种格式转换为 Julian Date 然后再转换为另一种格式会更慢,但是任何专门的转换算法本质上都是采用输入日期,将其转换为日期表示之间的某种中性 go,然后将其转换到所需的日历格式。然而,由于 Julian Date 是一种简单的单一数字格式,这实际上与转换为 Julian Date 然后再转换为其他格式相同,因此性能提升可以忽略不计。此外,日历转换可能不是任何应用程序性能的瓶颈,因此从中挤出最大可能的性能可能不会很好地利用任何人的时间。

关于algorithm - 为什么日历转换库围绕儒略日?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/8598880/

相关文章:

java - 使用 Java 转换 18 位十进制 Julian 时间戳

algorithm - 找出非相交凹多边形中边缘对齐的重叠矩形的最小数量

javascript - 选择另一个时重置单选按钮字段的最佳方法

javascript - 没有前导零的儒略日正则表达式

sql - 什么是儒略日期格式

jquery - 为什么我的 JQuery UI Datepicker 仅在单击时才翻译?

algorithm - 制作旋律创作基本算法的简单方法?

algorithm - 什么广告组合最赚钱

algorithm - 简单程序的复杂性

java - 设置 DAY_OF_WEEK 返回意外结果