Информация об изменениях

Сообщение Re[2]: Excel 29.02.1900 и .NET/C# от 01.07.2022 14:05

Изменено 01.07.2022 14:06 fortnum

Re[2]: Excel 29.02.1900 и .NET/C#
Здравствуйте, Xander Zerge, Вы писали:

XZ>Нет, потому что физически дата представляется длинным целым числом 100-наносекундных тиков после полуночи 1 января 1 года по Грегорианскому календарю, и после последнего тика 1900.02.28 сразу идёт первый тик 1900.03.01, поэтому "1900-02-29" DateTime-мом в принципе быть не может, только текстом.


Логично конечно, когда все к григорианскому календарю сводится. Проблема ведь именно в этом. Как перейти к другому календарю, не переписывая все форматирование дат. Фиг с ним с Excel'ем. Забудем о нём пока.

Вот есть еще как минимум один календарь. В юлианском 29.02.1900 — это законный день, потому что по нему 1900й год — високосный. И 1 тик в юлианском равен 1 тику в григорианском. То есть по юлианскому календарю после последнего тика 28.02.1900 наступает как раз 29.02.1900. Тики одни и те же, просто обозначение дней разное. Нет технических сложностей перевести день из юлианского в григорианский и обратно. Вот (вроде в браузере должно работать) получаем, что 29.02.1900 по юлианскому = 13.03.2900 по григорианскому:
using System;
using System.Globalization;

var dateTime = new DateTime(1900, 2, 29, new JulianCalendar());

Console.WriteLine(dateTime);


Но неужели никто не сделал форматирование этих юлианских дат в строку? Пока только Noda Time глянул мельком, но как я понял, она тоже это не умеет, вывести 29.02.1900 по юлианскому в строку.

Для юлианских дат нужны отдельные какие-то алгоритмы форматирования строк, чтобы выводить даты по тем же строкам форматирования, что и григорианские? Или там какой-то общий всё же алгоритм? Мн кажется, что должен быть общий, но пока еще не вникал.
Re[2]: Excel 29.02.1900 и .NET/C#
Здравствуйте, Xander Zerge, Вы писали:

XZ>Нет, потому что физически дата представляется длинным целым числом 100-наносекундных тиков после полуночи 1 января 1 года по Грегорианскому календарю, и после последнего тика 1900.02.28 сразу идёт первый тик 1900.03.01, поэтому "1900-02-29" DateTime-мом в принципе быть не может, только текстом.


Логично конечно, когда все к григорианскому календарю сводится. Проблема ведь именно в этом. Как перейти к другому календарю, не переписывая все форматирование дат. Фиг с ним с Excel'ем. Забудем о нём пока.

Вот есть еще как минимум один календарь. В юлианском 29.02.1900 — это законный день, потому что по нему 1900й год — високосный. И 1 тик в юлианском равен 1 тику в григорианском. То есть по юлианскому календарю после последнего тика 28.02.1900 наступает как раз 29.02.1900. Тики одни и те же, просто обозначение дней разное. Нет технических сложностей перевести день из юлианского в григорианский и обратно (хотя тут я не буду утверждать, может там и есть какая-то хитрость, надо разобраться). Вот (вроде в браузере должно работать) получаем, что 29.02.1900 по юлианскому = 13.03.2900 по григорианскому:
using System;
using System.Globalization;

var dateTime = new DateTime(1900, 2, 29, new JulianCalendar());

Console.WriteLine(dateTime);


Но неужели никто не сделал форматирование этих юлианских дат в строку? Пока только Noda Time глянул мельком, но как я понял, она тоже это не умеет, вывести 29.02.1900 по юлианскому в строку.

Для юлианских дат нужны отдельные какие-то алгоритмы форматирования строк, чтобы выводить даты по тем же строкам форматирования, что и григорианские? Или там какой-то общий всё же алгоритм? Мн кажется, что должен быть общий, но пока еще не вникал.