Проблема часового пояса NHibernate / SQLite с типом данных DateTime - отключение из-за ошибки смещения часового пояса - PullRequest
0 голосов
/ 25 марта 2020

Несмотря на то, что я четко указываю, что я хочу сделать все в UT C, где-то вдоль линии мои значения DateTime действуют так, как будто они записываются в БД SQLite в виде строк по местному времени, с часовой пояс не указан, затем считайте обратно, как если бы эти же цифры предназначались для времени UT C. Так как мой местный часовой пояс в настоящее время UT C -0400, это означает, что я считываю сэкономленное время, как если бы оно было на четыре часа старше, чем должно быть.

Значение DateTime определяется следующим образом:

    public class OrderModel
    {
        ...
        public virtual DateTime ReceivedTime { get; set; }
        ...

Отображение для этого значения выглядит следующим образом:

            {
                map.Column("RECEIVED_TIME");
                map.Type<NHibernate.Type.UtcDateTimeType>();
            });

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

    var sessionFactory = new TestSessionFactory();
    var session = sessionFactory.OpenSession();
    var transaction = session.BeginTransaction();
    var now = DateTime.UtcNow;
    var time1 = now.ToString("u");
    session.Save(new OrderModel() { ReceivedTime = now });
    transaction.Commit();
    session.Dispose();
    session = sessionFactory.OpenSession();
    var time2 = session.Query<OrderModel>().First().ReceivedTime.ToString("u");
    Console.WriteLine(time1 + ", " + time2);

Вывод кода выше: 2020-03-24 22:13:00Z, 2020-03-24 18:13:00Z

То же самое значение времени ... за исключением 4-часовой ошибки.

Что-нибудь, что мне не хватает? До сих пор я много занимался поиском ответов, но ничто не указывает на то, что мне нужно больше настроек. Я читал о других людях, которые сталкивались с подобной проблемой (однако многие годы go) и решили создавать свои собственные типы данных для решения этой проблемы, что, безусловно, кажется излишним для чего-то такого, что должно быть основополагающим c и универсально поддерживается как значение DateTime.

1 Ответ

0 голосов
/ 26 марта 2020

Мой босс придумал это исправление: добавив DateTimeKind=Utc к строке подключения.

Я нашел что-то похожее на это самостоятельно, но не совсем то же самое (что-то вроде Timezone=UTC, Я думаю) и это не помогло, но DateTimeKind=Utc сделал свою работу.

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