Как представить геологическое время? (Boost, Date_time?)

Я пытаюсь обработать данные временного интервала. Данные бывают двух форматов:

1) каждый интервал задан явно (например, 1982-12-31, 1988-01-01T00:00:00);

or

2) устанавливается начальная дата, за которой следует смещение в секундах, минутах, часах, днях, месяцах или годах

Я использовал комбинацию boost::gregorian::date и boost::posix_time::ptime для управления этим и использую средства для получения красиво отформатированных строк. Однако теперь мне представили данные, охватывающие 1,9 миллиона лет, причем каждый временной шаг составляет примерно 10 лет. Дата начала — 0, а последний интервал — 7e8. Очевидно, я достиг предела.

Есть ли способ использовать Boost для представления такого масштаба? Мои поиски привели к выводу «нет», и в этом случае мы просто напишем свой собственный класс.


c++ boost datetime gregorian-calendar
person jslmsca    schedule 17.07.2015    source источник
comment
Это типичный компьютерный компромисс: точность, дальность и потребляемая память. Если бы я был на вашем месте, я бы использовал структуру/класс, который имеет int32 года с начала какого-либо происхождения (1950 год является популярным во многих геофизических контекстах) и time_t или int или что-то еще, в котором есть секунды с начала года.   -  person wallyk    schedule 17.07.2015
comment
Спросите разработчика Ruby.   -  person Martin James    schedule 17.07.2015
comment
Я не знаю, в чем проблема. Ты не можешь использовать двойку? Обычно секунды и минуты становятся менее интересными при измерении в декадах, но даже это не должно быть проблемой: даже в самом большом масштабе (7e8) a double должен оставлять значащие цифры для представления интервалов ~3 сек.   -  person sehe    schedule 17.07.2015
comment
Можете ли вы привести примеры хорошо отформатированных входных/выходных данных для дат или интервалов, охватывающих 1,9 миллиона лет? Я искренне не знаю, как это будет выглядеть. У вас действительно есть 7-значный год плюс месяц и день: ГГГГГГГ-ММ-ДД?! Я подозреваю, что вам лучше написать свой собственный класс, который делегирует синтаксический анализ/форматирование библиотекам, которые вы уже используете для «обычных дат», но переключитесь на другой режим, когда все станет геологическим. Использование двойников в качестве базового представления может хорошо работать (происхождение рядом с «сейчас»), поскольку их характеристики точности, вероятно, соответствуют вашим нелинейным требованиям.   -  person duncan    schedule 17.07.2015
comment
Между прочим, вот алгоритмы, которые вам понадобятся, если вы хотите притвориться, что григорианский календарь действителен в таких временных масштабах: Howardhinnant.github.io/date_algorithms.html   -  person Howard Hinnant    schedule 18.07.2015
comment
@sehe -- Да, я буду использовать двойной. Мне просто интересно, есть ли средства Boost, которые справляются с этим, поскольку мой класс уже использует boost::posix::ptime и boost::gregorian.   -  person jslmsca    schedule 20.07.2015
comment
@duncan - Дело имитирует поток магмы. Он начинается с года 0, и каждый интервал добавляет дополнительные годы до года 7e8. Временных шагов примерно 194 тыс. Мне все еще нужно отображать год для определенных точек данных, но, очевидно, месяц и день не имеют значения.   -  person jslmsca    schedule 20.07.2015
comment
Формулировка вывода очень важна, потому что григорианский календарь считает фактические дни (солнце действительно восходит на востоке, пересекает небо и заходит на западе). Но в научных расчетах за длительные периоды времени неизменно используются дни, состоящие из 86 400 атомных секунд. Поскольку скорость вращения Земли постепенно уменьшается, это приведет к большим различиям в течение почти миллиарда лет. Вам следует проконсультироваться с учеными, выполняющими фундаментальную работу, чтобы определить правильное название шкалы времени, которую они используют.   -  person Gerard Ashton    schedule 31.07.2015

Ответы (1)


arrow_upward
2
arrow_downward

Это очень интересный вопрос. Но достижение пределов наддува в этой области требует тщательного осмысления риска выхода за сегодняшние астрономические пределы.

Календари и даты очень относительны:

  • Время Posix определяется как время, прошедшее с 1 января 1970 года, не считая високосных секунд. boost позволяет вам выбирать между микросекундным или наносекундным разрешением во время сборки.

  • Григорианский календарь установлен с 15 октября 1582 года. Обратите внимание, что до 1930 года в некоторых странах использовался григорианский календарь, а в некоторых все еще использовался юлианский, в результате чего в некоторых странах произошел интересные факты, такие как отсутствие 13 сентября 1752 года в Англии и Америке.

  • До этого был юлианский календарь, определенный И. Цезарем в 45 г. до н. э. Обратите внимание, что хотя формат, количество месяцев и продолжительность месяца такие же, как и в григорианском календаре, разница между ними составляет 13 дней, что учитывает накопленные различия за годы.

  • до 45 г. до н.э. существовал старый римский календарь, в котором было 355 дней в году.

  • А раньше, до начала человечества, конечно, были и другие календари. Но сутки не всегда были 24 часа. Вариации солнечных суток от 1 до 3 микросекунд в день складываются, если вы входите в миллионы лет. Например, 600 миллионов лет назад средняя продолжительность суток составляла всего 22 часа.

Если вы работаете как в геологическом, так и в узком масштабе, самым простым подходом может быть использование класса или объединения, объединяющего long long (для геологического масштаба в годы до н. ). Тогда красивое форматирование было бы относительно легко организовать.

В качестве альтернативы вы можете рассмотреть возможность использования chrono с самым длинным целочисленным типом и соотношением, указывающим, что вы считая годы:

typedef chrono::duration<long long, ratio<31556926, 1>> duration_in_year;
duration_in_year d2(1900000); // 1,9M years
chrono::time_point<chrono::system_clock> t1 = chrono::system_clock::now() - d2;

но красивая распечатка будет не так бросаться в глаза, как с boost. И вам нужно будет определить свой собственный класс часов (приведенный выше пример будет работать с 1,9 миллионами лет, но не намного больше, из-за параметров, используемых для создания экземпляра класса system_clock).

person Christophe    schedule 17.07.2015
comment
Спасибо, Кристоф. Это было полезно для рассмотрения при разработке класса, который может обрабатывать как узкое, так и крупномасштабное время. - person jslmsca; 20.07.2015