:: Не фоксом единым
CURRENT_TIMESTAMP vs LOCALTIMESTAMP
S-type

Сообщений: 2969
Дата регистрации: 24.04.2004
Как сказано на postgrespro.ru

Цитата:
CURRENT_TIMESTAMP возвращают время с часовым поясом. В результатах LOCALTIMESTAMP нет информации о часовом поясе.

Ещё понятно, что это как то позволяет решать какие то проблемы с написанием программ, работающих одновременно работающих в разных регионах. Вопрос - а какие бывают проблемы? Предположим, есть MVC программа, ей пользуются из разных часовых поясов. Какие тут проблемы?
Ratings: 0 negative/0 positive
Re: CURRENT_TIMESTAMP vs LOCALTIMESTAMP
Vedmak
Автор

Сообщений: 5949
Откуда: CiTY
Дата регистрации: 30.10.2003
Например, расчетные карты . В решении у клиента 3 часовых пояса.

Авторизационный сервер платежных карт находится "в середине", т.е. ожидаются запросы от касс со смещением времени в диапазоне +/- час.

Пример:

При авторизации оплаты картой касса ( с локальным временем +1) отправляет запрос к серверу ( с локальным временем +0). Авторизационный сервер (АС) обслуживает запрос в своем часовом поясе (+0) и фиксирует записи и отправляет результат кассе.

В обычном учете времени "как есть" получится, что транзакция (регистрация продажи), будет раньше на час чем предоставление разрешения на эту покупку (авторизация).

Проблема рождается при анализе конфликтных ситуаций. Что же было раньше авторизация карты или расчет покупки ?

Когда все идеально работает, таки мелочи не кажутся очевидными. НО когда на кону серьезные деньги, то с часовыми поясами стоит возиться однозначно.

P.S. И часы всех хостов надо синхронизировать с единым эталоном. Раз в сутки.


------------------
Говорить стоит лишь для тех, кто слушает.




Исправлено 6 раз(а). Последнее : Vedmak, 22.08.19 22:56
Ratings: 0 negative/0 positive
Re: CURRENT_TIMESTAMP vs LOCALTIMESTAMP
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
Если хранить "локальное время", то сервер из Москвы и сервер из Лондона запишут что некоторые события произошли в 0:20, тогда как на самом деле между ними прошло 2-3 часа (в Лондоне ещё переводят часы на зимнее/летнее время ).
Если передавать с сервера на клиента (в браузер) "локальное время", и там никак его не обрабатывать (а его и не обработаешь корректно, если при передаче не указать часовой пояс этого самого передаваемого datetime), то пользователь из Москвы будет видеть часы со смещением на 2-3 часа. Ну т.е. вот сейчас он увидит 22:30. Аналогично при вводе данных - если ты в браузере введёшь в поле ввода даты-времени 0:30, то не удивляйся что тебе позвонят или там пришлют сообщение в 2 часа по Москве.
Вообще тема даты-времени просто таки необъятна, и вряд ли можно осветить все проблемы и нюансы в одном посте
И подходы к хранению передаче и использованию даты-времени тоже разнообразны. Просто "локальное время без часового пояса" применимо лишь для размещения всей инфраструктуры и клиентов в рамках одного часового пояса - и крайне желательно чтобы это был часовой пояс БЕЗ перевода на зимнее/летнее время - ну иначе придётся смириться с потерей 1 часа или с "лишним" часом при вычислении разницы между 2-мя датами.
Хранить всё в UTC - один из вариантов, но его недостаток - требуется переводить это время в "местное" для отображения - при том желательно лишь "на клиенте".
Хранить в виде "местное время с указанием часового пояса" - ещё более мощная штука, т.к. помимо всегда точного перевода в UTC (конечно, если реализация хорошая - хватает всяких сложностей), ещё и хранится информация о часовом поясе клиента - т.е. грубо говоря можно приветствовать его "доброе утро", когда в месторасположении сервера уже давно поздний вечер.
P.S. Сейчас нечасто встречаются "чистые" MVC приложения - хоть какой-то объём js кода наверняка будет в проге... Те же "календарики" это почти наверняка клиентский рендеринг будет.


------------------
WBR, Igor
Ratings: 0 negative/0 positive
Re: CURRENT_TIMESTAMP vs LOCALTIMESTAMP
S-type

Сообщений: 2969
Дата регистрации: 24.04.2004
Igor Korolyov
и крайне желательно чтобы это был часовой пояс БЕЗ перевода на зимнее/летнее время
Мне просто не верится, что дожил до того, как этот маразм с переводом времени прекратили.

Всё таки, немного не понимаю - как это работает. www.postgresql.org

[attachment 31705 s1.png]

Если поле типа timestamp with time zone, то в базе хранится значение "время + зона"? А когда клиент запрашивает информацию из поля типа timestamp with time zone, то от значения из поля отнимается зона, в которой находится клиент? Так это работает?
Ratings: 0 negative/0 positive
Re: CURRENT_TIMESTAMP vs LOCALTIMESTAMP
pasha_usue

Сообщений: 3647
Откуда: Е-бург
Дата регистрации: 06.10.2006
Так.

С клиента:
SHOW TimeZone;
SET TimeZone TO +5;
Ratings: 0 negative/0 positive
Re: CURRENT_TIMESTAMP vs LOCALTIMESTAMP
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
К сожалению нет - в постгресе timestamp with time zone просто хранит дату-вермя в UTC, и просто переводит его при обращении, используя либо заданные в самом текстовом значении суффиксы (смещение часового пояса, или его имя), либо текущие настройки сессии. Это решает многие проблемы, но далеко не все. Да и всяких тонкостей при работе с этим типом хватает. Одна невозможность строить простые индексы по такому полю чего стоит (это и логично, индекс по сути хранит значения, а как можно хранить то, что зависит от "точки зрения пользователя" - для одного это 11 вечера 23-го числа, а для другого 1 час ночи 24-го).
Сам часовой пояс клиента нигде не хранится - если надо, то следует его отдельно сохранять (может быть вместе с каждой датой, может быть хватит и одной настройки для выставления в сессии, чтобы с её помощью переводить все даты видимые этим пользователем)...


------------------
WBR, Igor
Ratings: 0 negative/0 positive
Re: CURRENT_TIMESTAMP vs LOCALTIMESTAMP
Vedmak
Автор

Сообщений: 5949
Откуда: CiTY
Дата регистрации: 30.10.2003
Хе-хе. Я мыслю в рамках бизнес логики.

Про "где хранится признак часового пояса хоста" стоит создать отдельное обсуждение с учетом различных подходов: Windows, Linux и ОС из Mac-ордора.


------------------
Говорить стоит лишь для тех, кто слушает.
Ratings: 0 negative/0 positive


Извините, только зарегистрированные пользователи могут оставлять сообщения в этом форуме.

On-line: 9 (Гостей: 9)

© 2000-2024 Fox Club 
Яндекс.Метрика