[Слесарь 9]

Помнится, вопрос расчета времени по календарю не такой и простой как в приведенных формулах, помнится даже CTime от микрософт не всегда качественно справлялся с этой задачей. Если вопрос принципиален могу покапаться в архивах и привести парочку вариантов возникновения ошибки в реальных приложениях где производится расчет промежутка времени.

 

вот например

 

CDate::CDate(const SYSTEMTIME &st)
{
    /* Так как бывает летнее и зимнее время, возьмем
        за базу полдень. Что бы перевод времени не влиял
        на дату. То есть, если за базу берется полночь
        переход на летнее время после зимнего может произвести
        при вычислении BackDay() пропуск целой даты.
    */
    CTime t( st.wYear, st.wMonth, st.wDay, 12, 0, 0 );

    m_time = t;
}

[adnega 11]

Помнится, вопрос расчета времени по календарю не такой и простой как в приведенных формулах

Возможно, но для 2000 - 2099 годов работает для любой даты. Проверял перебором.

[Слесарь 9]

странно, разве вам известно как распределится время в промежутке 2014 ... 2099 годах? Время ведь понятие человеческое, людям свойственно менять отношение к собственным понятиям. Вспомните Мюнхаузена с его 32 числом, ведь это нововведение вполне может быть легализовано в один прекрасный момент, как собственно недавняя приписка чуть более десятка дней к календарю.

[haker_fox 61]

странно, разве вам известно как распределится время в промежутке 2014 ... 2099 годах? Время ведь понятие человеческое, людям свойственно менять отношение к собственным понятиям. Вспомните Мюнхаузена с его 32 числом, ведь это нововведение вполне может быть легализовано в один прекрасный момент, как собственно недавняя приписка чуть более десятка дней к календарю.

При переводе даты в количество секунд (минут) нужно учитывать високосные годы. Как, написано много где. Вроде все. Количество дней в месяцах кроме февраля - фиксированное.

[Слесарь 9]

Рас читывать количество месяцев за промежуток времени по секундам, достаточно сомнительное занятие. Учитывать только секунды при расчете даты, это прямолинейное ориентирование только на один ориентир Солнце. Ошибка в расчете количества месяцев присутствует постоянно.

Кста есть значимые свидетельства ошибок таких расчетов, например католическая Пасха рассчитывается по григорианскому солнечному календарю (учитывается только солнечный год, календарь прямолинейный, как по секундам), католики часто нарушают правило праздновать Пасху в первое воскресенье после наступления полнолуния, которое выпадает на период после весеннего равноденствия. После празднования иудейской Пасхи, если случается совпадение, то правила предписывают перейти к полнолунию следующего месяца.

В настоящее время католическая пасха часто празднуется раньше иудейской, что строго запрещается церковными канонами.

[adnega 11]

Время ведь понятие человеческое, людям свойственно менять отношение к собственным понятиям.

Все просто: приведенные формулы годятся для существующего сейчас календаря.

Когда календарь поменяют, тогда поменяем и формулы.

Привязываться к астрономической точности в рамках решаемой задачи явный перебор.

Эдак можно задачу и не решить... ведь в сутках не ровно 24 часа... да и вращается Земля вокруг

собственной оси с небольшим снижением оборотов...

А если два события происходят в разных точках пространства... или по разные стороны "линии перемены дат"...

Условностей много, и это еще без привлечения религий))

[d7d1cd 0]

Сразу хочу сказать спасибо всем за помощь. Алгоритм приведенный adnega вполне подходит. Только объясните мне, почему если месяц меньше 3-х, то необходимо год уменьшить на 1, а количество месяцев увеличить на 12?

[adnega 11]

Только объясните мне, почему если месяц меньше 3-х, то необходимо год уменьшить на 1, а количество месяцев увеличить на 12?

Видимо, чтобы "изменчивый" февраль был в конце.