|
npgsql timestamp with time zone
|
|||
---|---|---|---|
#18+
Достался тут проект с нет кор и пг.. поля с временем в бд как понятно из топика типа timestamp with time zone. на 3.1 бахнули до меня DateTimeOffset и работало. тут решили проект перекатить на 6ку и обновили npgsql и получили Cannot write DateTime with Kind=Unspecified to PostgreSQL type 'timestamp with time zone', only UTC is supported открыл доку https://www.npgsql.org/doc/types/datetime.html а там просто DateTime. Я правильно понимаю до меня ребята наворотили с DateTimeOffset и надо было изначально DateTime или это особенность что ментейнеры npgsql переписали в 6ке? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.12.2021, 21:29 |
|
npgsql timestamp with time zone
|
|||
---|---|---|---|
#18+
handmadeFromRu, При работе с npgsql, ты должен работать только с UTC. При чём по барабану, DateTimeOffset у тебя, или DateTime: DateTimeOffset должно иметь смещение 0, а DateTime должен иметь Kind = Utc. И это на самом деле очень правильно. Но может показаться несколько неожиданно. Если коротко. Забудь про локальную дату/время. Время на сервере тебя больше никогда не должно волновать ни в каком качестве от слова _АБСОЛЮТНО_ :) С этим связано небольшие затраты на то, чтобы обеспечить приведение времени к UTC перед записью в БД. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2021, 00:11 |
|
npgsql timestamp with time zone
|
|||
---|---|---|---|
#18+
handmadeFromRu, Да, это последние нововведения от команды npgsql, которые в прочем можно отключить. Но я бы не советовал. Всё правильно делают. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2021, 00:11 |
|
npgsql timestamp with time zone
|
|||
---|---|---|---|
#18+
hVostt Всё правильно делают. Чото у меня сомнения в их правильности. Если мне надо, например не просто указать что это 11:15 вечера 5 августа 1945 года по UTC, а 8:15 утра 6 августа 1945 по Токио, то как мне тогда быть? Если такое невозможно, то на кой фер нужна поддержка TZ в БД? Она как бы для этого и задумана. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2021, 03:38 |
|
npgsql timestamp with time zone
|
|||
---|---|---|---|
#18+
fkthat Чото у меня сомнения в их правильности. Если мне надо, например не просто указать что это 11:15 вечера 5 августа 1945 года по UTC, а 8:15 утра 6 августа 1945 по Токио, то как мне тогда быть? Если такое невозможно, то на кой фер нужна поддержка TZ в БД? Она как бы для этого и задумана. Поддержка TZ в БД это умение привести время при запросе к нужному часовому поясу. Но храниться должно, строго-настрого, исключительно момент времени, т.е. UTC. При необходимости учитывать TZ для отдельных записей, хранить его отдельным полем. К слову, в отличие от MS SQL, у Postgres нет типа данных, который умеет хранить дату/время + смещение. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2021, 03:42 |
|
npgsql timestamp with time zone
|
|||
---|---|---|---|
#18+
hVostt Поддержка TZ в БД это умение привести время при запросе к нужному часовому поясу. Нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2021, 04:16 |
|
npgsql timestamp with time zone
|
|||
---|---|---|---|
#18+
fkthat hVostt Поддержка TZ в БД это умение привести время при запросе к нужному часовому поясу. Нет. А чего ещё надо-то? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2021, 04:42 |
|
npgsql timestamp with time zone
|
|||
---|---|---|---|
#18+
hVostt А чего ещё надо-то? :) Если бы все было так просто, то отдельный тип данных для этого был бы не нужен - сохраняй себе все в обычном datetime в UTC и все. Но когда ты преобразовываешь время от времени с указанной таймзоной к UTC ты всегда теряешь информацию. Если у тебя сценарий где она не важна, то это пофиг, но можно придумать сценарии где она нужна и тогда тебе всё равно при этом придется каким-то ручным образом еще и таймзону хранить, а зачем эта лишняя морока, если есть готовый тип данных для этого. Я просто еще не знаю, что там за морока с PG, но MSSQL с этим работает абсолютно нормально, когда ты в БД и в БД и на клиенте используешь DateTimeOffset. Но, вообще говоря, DateTimeOffset тоже все проблемы совсем не решает, потому что таймзона это далеко не просто разница с UTC. Собственно про это много можно здесь найти: https://nodatime.org/ ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2021, 05:25 |
|
npgsql timestamp with time zone
|
|||
---|---|---|---|
#18+
hVostt handmadeFromRu, Да, это последние нововведения от команды npgsql, которые в прочем можно отключить. Но я бы не советовал. Всё правильно делают. ага я видел хаку в доке на отключение но не любитель хак впринципе. так я понял что храниться в utc, получается он читает то потом в какой локале из utc? по настройкам конекшена или локального сервера? hVosttDateTimeOffset должно иметь смещение 0, а DateTime должен иметь Kind = Utc я что то должен скидывать ? не понял тут. в итоге мне надо все поля в сущностях из DateTimeOffset в DateTime перегнать, с учетом что дока говорит что у них DateTime это timestamp with time zone? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2021, 06:56 |
|
npgsql timestamp with time zone
|
|||
---|---|---|---|
#18+
handmadeFromRu я что то должен скидывать ? не понял тут. в итоге мне надо все поля в сущностях из DateTimeOffset в DateTime перегнать, с учетом что дока говорит что у них DateTime это timestamp with time zone? Чота они там намутили. Надо самому проверять, т.к. мы как раз хотели все перешерстить и на DateTimeOffset перевести. Сейчас у нас как раз в БД timestamp with TZ, на клиенте DateTime в UTC. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2021, 07:17 |
|
npgsql timestamp with time zone
|
|||
---|---|---|---|
#18+
https://www.roji.org/postgresql-dotnet-timestamp-mapping еще что нашел ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2021, 08:43 |
|
npgsql timestamp with time zone
|
|||
---|---|---|---|
#18+
fkthat Если бы все было так просто, то отдельный тип данных для этого был бы не нужен - сохраняй себе все в обычном datetime в UTC и все. Но когда ты преобразовываешь время от времени с указанной таймзоной к UTC ты всегда теряешь информацию. Если у тебя сценарий где она не важна, то это пофиг, но можно придумать сценарии где она нужна и тогда тебе всё равно при этом придется каким-то ручным образом еще и таймзону хранить, а зачем эта лишняя морока, если есть готовый тип данных для этого. Я просто еще не знаю, что там за морока с PG, но MSSQL с этим работает абсолютно нормально, когда ты в БД и в БД и на клиенте используешь DateTimeOffset. Но, вообще говоря, DateTimeOffset тоже все проблемы совсем не решает, потому что таймзона это далеко не просто разница с UTC. Собственно про это много можно здесь найти: https://nodatime.org/ Сценарий где нужно хранить часовой пояс -- храним отдельно, как нужно. А момент времени это момент времени, не больше и не меньше. Т.е. UTC. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2021, 19:43 |
|
npgsql timestamp with time zone
|
|||
---|---|---|---|
#18+
handmadeFromRu так я понял что храниться в utc, получается он читает то потом в какой локале из utc? по настройкам конекшена или локального сервера? Нет. Всё UTC. И на чтение и на запись :) Чтобы приводить к нужному поясу, указываешь в запросе явно. Или приводишь на клиенте. handmadeFromRu я что то должен скидывать ? не понял тут. в итоге мне надо все поля в сущностях из DateTimeOffset в DateTime перегнать, с учетом что дока говорит что у них DateTime это timestamp with time zone? Да, придётся скидывать в UTC, что DateTime, что DateTimeOffset перед записью в БД. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2021, 19:44 |
|
npgsql timestamp with time zone
|
|||
---|---|---|---|
#18+
fkthat БД timestamp with TZ Стоит всё же понять, что никакого TZ там в таймстампе нет. На эту граблю уже тысячи напоролись :) ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2021, 19:45 |
|
npgsql timestamp with time zone
|
|||
---|---|---|---|
#18+
hVostt Стоит всё же понять, что никакого TZ там в таймстампе нет. На эту граблю уже тысячи напоролись :) Ах ты блин, вон оно что... Понятно, спс, что предупредил. Так а если мне все-таки хочется хранить с таймзоной? Хоронить всякий раз руками? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2021, 20:01 |
|
npgsql timestamp with time zone
|
|||
---|---|---|---|
#18+
hVostt, Документация ПГ божится, что ТЗ там есть. https://www.postgresql.org/docs/9.5/datatype-datetime.html Кому верить. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2021, 20:30 |
|
npgsql timestamp with time zone
|
|||
---|---|---|---|
#18+
hVostt Сценарий где нужно хранить часовой пояс -- храним отдельно, как нужно. "Как нужно" - это как в MS SQL, где все это по людски работает безо всякой ручной мастурбации :)) ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2021, 20:31 |
|
npgsql timestamp with time zone
|
|||
---|---|---|---|
#18+
fkfka Так а если мне все-таки хочется хранить с таймзоной? Хоронить всякий раз руками? Да, отдельно. Например, есть филиалы в разных городах, соответственно с разным часовым поясом. Часовой пояс хранится для филиала. Не нужно хранить для каждого документа филиала смещение, хранится в одном месте. Или. Например, у каждого пользователя свой часовой пояс, вынесенный в настройки. Берём его оттуда. fkfka Документация ПГ божится, что ТЗ там есть. https://www.postgresql.org/docs/9.5/datatype-datetime.html Кому верить. with timezone следует читать как "учитывая часовой пояс". Такой тип не рекомендуется использовать, так как будет учитываться часовой пояс сервера -- а это очень плохо. fkfka "Как нужно" - это как в MS SQL, где все это по людски работает безо всякой ручной мастурбации :)) Там по сути тоже не часовой пояс, а обычное смещение. Что не совсем одно и то же, что часовой пояс. Так как не учитываются летнее/зимнее время и различные смещения в разные эпохи. В общем, смещение это плохо. Хранить локальное время в БД плохо. Не делайте так :) ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2021, 20:40 |
|
npgsql timestamp with time zone
|
|||
---|---|---|---|
#18+
Есть исключение из правил. Это тип date, а также соответствующий тип в .NET DateOnly. Т.е. это календарная дата. Хорошо подходит бизнесу, например, дата договора. Пользуйтесь :) Единственная проблема, с которой наверняка столкнётесь при использовании типа DateOnly, стандартный System.Text.Json сериализатор не умеет с ним работать :( ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2021, 20:42 |
|
npgsql timestamp with time zone
|
|||
---|---|---|---|
#18+
hVostt Да, придётся скидывать в UTC, что DateTime, что DateTimeOffset перед записью в БД. я перевел все поля DateTimeOffset в DateTime я хз кто с кем договорился но нет6 в памяти DateTime держит как в бд лежит т.е. UTC. а при вставке самое конвертит DateTime в UTC DateTime п.с. вообщем по тихому не получилось перекатиться на нет6 ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2021, 20:52 |
|
npgsql timestamp with time zone
|
|||
---|---|---|---|
#18+
handmadeFromRu я перевел все поля DateTimeOffset в DateTime я хз кто с кем договорился но нет6 в памяти DateTime держит как в бд лежит т.е. UTC. а при вставке самое конвертит DateTime в UTC DateTime тоже норм handmadeFromRu п.с. вообщем по тихому не получилось перекатиться на нет6 из нашего опыта сложнее всего было перейти с EF Core 2, на 3+ ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2021, 20:57 |
|
npgsql timestamp with time zone
|
|||
---|---|---|---|
#18+
вообще если капнуть глубже то проблема времени капец геморная даже скит о таком писал в далеком 2019 https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/ все в утс не решает всего гемороя ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2021, 22:58 |
|
npgsql timestamp with time zone
|
|||
---|---|---|---|
#18+
hVostt Там по сути тоже не часовой пояс, а обычное смещение. Что не совсем одно и то же, что часовой пояс. Да, я про это как раз писал выше. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2021, 23:03 |
|
npgsql timestamp with time zone
|
|||
---|---|---|---|
#18+
handmadeFromRu все в утс не решает всего гемороя Джон Скит конечно заморочился и всё верно говорит, но его нода тайм это капец переусложнённое решение. Всё в UTC устраняет любой гемор, так как это момент времени. Т.е. настоящее время события, которое можно привести к чему угодно, к любому локальному времени в любой эпохе. Тут сложность не техническая, а предметная. Да, люди придумали себе гемор на задницу с переводом часов и периодической сменой смещения. Именно поэтому нужно не ибсти мозги со всякими нодатаймами, а хранить время в UTC. Шо тут сложного-то :) ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2021, 23:33 |
|
npgsql timestamp with time zone
|
|||
---|---|---|---|
#18+
handmadeFromRu даже скит о таком писал в далеком 2019 https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/ Учитывая, что серебряной пули не существует, писать как что-то тама "не серебряная пуля" выглядит немного комично. Капец-капец, мир оказывается сложный! Радоваться надо. Это же наш хлебушек ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2021, 23:36 |
|
|
start [/forum/topic.php?fid=18&fpage=1&tid=1354458]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
27ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
61ms |
get tp. blocked users: |
2ms |
others: | 10ms |
total: | 142ms |
0 / 0 |