2011-12-22 16 views
4

В настоящее время я пишу код php для преобразования дат из Григорианского календаря в календарь на иврите. Глядя на функции календаря php, я обнаружил, что у него есть функции для преобразования с григорианского на юлианские дни и юлианские дни на иврит. Однако нет никакой функции, которую я мог бы найти, чтобы напрямую преобразовать из григорианского языка в иврит.Почему библиотеки преобразования календарей вращаются вокруг юлианских дней?

Из любопытства я хотел посмотреть, возможно ли прямое преобразование. Хотя, исследуя это, я обнаружил, что, похоже, стандартно конвертировать даты в юлианские дни, а затем в нужную систему календаря.

Я нашел это в нескольких библиотеках, как: 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

Что меня беспокоит, почему! Является ли это стандартом, принятым какой-то группой? Это делается исторически?

Не было бы более эффективным придумать алгоритмы прямого преобразования дат? или, наоборот, что делает Джулианские дни такими эффективными?

ответ

7

Если вы хотите преобразовать разные календари, и вы реализовали алгоритмы для перехода из любого формата в любой другой формат, вам понадобится n^2 - n алгоритмов преобразования. Однако, если вместо этого писать алгоритмы для преобразования любого формата календаря в один базовый формат календаря, а затем писать алгоритмы для преобразования из базового формата в любой другой формат, вам нужно только написать алгоритмы 2(n-1).

Эти форматы календаря представляют собой одно и то же, время. Самый простой способ представить время - это количество времени, прошедшего с некоторой точки отсчета, так что он имеет наибольший смысл в качестве базового формата. Это как раз то, что Julian Date, количество дней с 1 января 4713 года до н.э. Гринвичский полдень.

Возможно, вы подумали, что это будет медленнее конвертировать из одного формата в Julian Date, а затем в другой формат, однако любой специализированный алгоритм преобразования, по сути, будет принимать входную дату, преобразовывать ее в какой-то нейтральный переход между представлением даты и затем конвертировать это в желаемый формат календаря. Однако, поскольку Julian Date представляет собой простой формат с одним номером, это фактически то же самое, что и преобразование в Julian Date, а затем преобразование в какой-либо другой формат, поэтому прирост производительности будет незначительным. Кроме того, конверсии календаря, вероятно, не являются узким местом производительности любого приложения, поэтому сжатие наиболее возможной производительности из них, вероятно, не очень полезно для чьего-либо времени.

+0

Я понимаю, что это, вероятно, не было бы узким местом, казалось, что использование обычного «среднего человека» между несколькими различными системами было странным решением. Теперь это имеет больше смысла, особенно с точки зрения обслуживания. –

+3

Почти любой тип конверсии будет использовать своего рода «средний человек». Скажем, вы конвертируете изображение из JPEG в PNG. Вы не собираетесь брать данные JPEG и напрямую конвертировать его в PNG. Вы собираетесь распаковать JPEG в растровое изображение, чтобы получить значения цвета каждого пикселя, а затем сжать его в формате PNG. Превращение с прямым преобразованием из сжатия JPEG в сжатие PNG было бы очень сложным. –