Каков (лучший) способ обработки дат до Рождества Христова в C # / .NET? - PullRequest
18 голосов
/ 18 мая 2009

Есть ли встроенная поддержка для этого? А если нет, есть ли согласие относительно обработки таких дат?


Ссылки на собственные кодовые решения или их фрагменты приветствуются.

Ответы [ 3 ]

9 голосов
/ 18 мая 2009

В этом диапазоне нет встроенной поддержки дат, поэтому вам придется кодировать свои собственные.

Вот пример http://flipbit.co.uk/2009/03/representing-large-ad-and-bc-dates-in-c.html.

4 голосов
/ 18 мая 2009

Если вы ссылаетесь на обработку значений DateTime

Любой консенсус может существовать только в сообществе, которое работает с такими датами. В какой области вы работаете? Астрономия


Какой бы ни была сфера интересов, вероятно, есть другие, кто столкнулся с такой же проблемой. Сначала я бы провел небольшое исследование, особенно если ваши даты когда-нибудь будут взаимодействовать с другим программным обеспечением в той же области интересов. Даже если вам придется кодировать свой собственный код, вы, по крайней мере, сможете узнать о проблемах, с которыми другие столкнулись при кодировании своих своих.

2 голосов
/ 12 января 2016

Я знаю, что этот вопрос старый, но я нашел его в поиске и могу добавить дополнительную информацию к этой теме. В комментариях выше кто-то утверждал, что разница в датах будет больше 1 года. Если кто-то не планирует вернуться ко времени задолго до того, как можно будет с пользой получить точные даты (многие тысячи лет), это не так. Дифференциал, необходимый как для юлианских, так и для григорианских дат, составляет лишь небольшое количество дней, определенно менее 3 недель для любой конкретной даты, которую можно разумно попытаться извлечь из существующих исторических записей. Для этого есть конверсионные таблицы. Я считаю, что большая проблема связана с переходом на григорианский календарь.

Разные страны конвертировали в разное время и теряли разное количество дней, когда они конвертировали, потому что они не конвертировали в одно и то же время. Для примера того, как произошла конверсия, представьте, что сегодня 1 октября, а завтра 10 октября. В этом случае конверсия приведет к потере 9 дней в этой конкретной стране. Другая страна, которая перешла через некоторое время, может потерять 11 дней, или 12 дней, или 13 дней и т. Д. Еще одна большая проблема - попытка определить сезон на определенную дату. Из-за неточных календарей прецессия равноденствий привела к довольно быстрой прогрессии сезонов через календарный год с течением времени. Сегодня у нас лето в северном полушарии в июле месяце. 3000 лет назад этот календарный месяц мог произойти в середине зимы, если мы используем юлианский календарь в качестве нашего стандарта.

Также важно отметить, что в древнем мире использовалось множество древних календарных систем. Существовали как солнечные, так и лунные разновидности, и до 2000 лет назад (когда был изобретен юлианский календарь) реально эффективной попытки стандартизации не было. Люди часто пытаются спроецировать юлианские даты гораздо глубже в историю, но эти усилия анахроничны. Из-за неопределенности, вызванной противоречивыми записями, невозможно определить конкретное событие, произошедшее в конкретную дату, коррелированную с юлианским календарем, за исключением случаев, когда используется многократная ошибка, которая включает в себя довольно большую погрешность. Для события, произошедшего до первого тысячелетия до нашей эры, этот предел погрешности может составлять 50 или 100 лет (или более в определенные периоды). У нас просто нет записей, чтобы установить чрезвычайно точные сроки. Углеродные даты, полученные из последовательностей древовидных колец, сопоставленных с существующими записями, помогли уменьшить допустимый предел погрешности в различных регионах и периодах, но они не составляют полностью связанную запись, и у нас всегда будет допустимый предел погрешности.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...