|
Firebird 4: Could not find acceptable ICU library
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, ну я вот почитал обсуждения в devel и никаких разумных предложений не увидел. Тогда уж лучше так как есть чем совсем никак ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2019, 21:27 |
|
Firebird 4: Could not find acceptable ICU library
|
|||
---|---|---|---|
#18+
Симонов Денися вот почитал обсуждения в devel и никаких разумных предложений не увидел Предложение Влада, по-моему, вполне ништяк. Приложение получает идентификатор и смещение, а дальше вольно делать с ними всё, что угодно. Вышеназванные функции идут лесом, для получения названий часовых поясов используется либо таблица на сервере, либо захаркоденная. Второе удобнее, ибо решает ещё и проблему с локализацией. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2019, 21:40 |
|
Firebird 4: Could not find acceptable ICU library
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, а... это да, я за ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2019, 21:48 |
|
Firebird 4: Could not find acceptable ICU library
|
|||
---|---|---|---|
#18+
Симонов Денисэто да, я за Там даже Кейн был не против, что весьма редкое явление. Хотя я так и не понимаю зачем ему в исторических данных секундная точность смещения у пояса. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2019, 22:32 |
|
Firebird 4: Could not find acceptable ICU library
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovСимонов Денисс этим не стоит торопиться, может нам с Владом ещё удастся убедить Адриано сделать по человечески Похоже, попытка провалилась.Я так не считаю пока что ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2019, 23:14 |
|
Firebird 4: Could not find acceptable ICU library
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovПриложение получает идентификатор и смещение, а дальше вольно делать с ними всё, что угодно.Я пока что не вижу обоснования - почему приложение вообще получает время в UTC. Так что, пока меня не убедят в том, что так и надо - я считаю что нужно на клиента передавать региональное время, как оно было изначально. И, есс-но, с клиента тоже передавать региональное время, а сервер уже сам пусть его превращает в UTC для хранения и сравнения. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2019, 23:16 |
|
Firebird 4: Could not find acceptable ICU library
|
|||
---|---|---|---|
#18+
hvladЯ так не считаю пока что Я буду мысленно болеть за тебя. Удачи. PS: На твой вопрос в девеле "почему UTC": боюсь, что за это в ответе я. Когда это ещё только обсуждалось, я был молод и наивен, а потому написал "UTC + offset, что может быть проще?" Ну, внезапно Адриано повёлся. Хотя именно в форме "нечто + смещение" это сугубо всё равно. Что напишете в доке, то и ладненько. Проблема выползла когда Адриано начал выдавать ид вместо смещения. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2019, 23:24 |
|
Firebird 4: Could not find acceptable ICU library
|
|||
---|---|---|---|
#18+
hvladя считаю что нужно на клиента передавать региональное время, как оно было изначально. Тут есть один нюанс: когда время передаётся в виде литерала в запроса, оно, конечно, удобнее региональное. Ибо читабельность. А вот в бинарной форме через API будет удобнее UTC тупо потому, что time() его возвращает и не надо париться с дальнейшим переводом в localtime(). Хотя, конечно, на вкус и цвет фломастеры разные, но я придерживаюсь паттерна KISS... Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2019, 23:28 |
|
Firebird 4: Could not find acceptable ICU library
|
|||
---|---|---|---|
#18+
hvladЯ пока что не вижу обоснования - почему приложение вообще получает время в UTC. Так что, пока меня не убедят в том, что так и надо - я считаю что нужно на клиента передавать региональное время, как оно было изначально. И, есс-но, с клиента тоже передавать региональное время, а сервер уже сам пусть его превращает в UTC для хранения и сравнения. теоретически время в UTC может потребоваться если клиент решит преобразовать его в другой часовой пояс, не тот что пришёл с сервера. Других случаев я не вижу ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2019, 23:48 |
|
Firebird 4: Could not find acceptable ICU library
|
|||
---|---|---|---|
#18+
Симонов Денис можно тебя попросить написать тикет в трекер, чтобы добавили контекстную переменную 'TIME_ZONE', хранящую строковый идентификатор часового пояса, в пространства имён 'SYSTEM'(часовой пояс сервера) и 'USER_SESSION'(часовой пояс клиента)? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.06.2019, 09:27 |
|
Firebird 4: Could not find acceptable ICU library
|
|||
---|---|---|---|
#18+
rdb_dev, сам не умеешь что ли? Вроде уже тикеты писал ... |
|||
:
Нравится:
Не нравится:
|
|||
14.06.2019, 09:34 |
|
Firebird 4: Could not find acceptable ICU library
|
|||
---|---|---|---|
#18+
Симонов Денис, по всей видимости, я малопонятно формулирую. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.06.2019, 09:55 |
|
Firebird 4: Could not find acceptable ICU library
|
|||
---|---|---|---|
#18+
rdb_dev, чтобы я захотел за кого-то оформить тикет меня надо убедить в его необходимости. Давай сначала с понятиями разберёмся. С точки зрения сервера никакого клиентского часового пояса нет. Есть часовой пояс установленный для сессии. Серверного часового пояса вроде как нет совсем, есть часовой пояс который ставится для сессии по умолчанию, если иное указание не пришло с клиента. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.06.2019, 10:11 |
|
Firebird 4: Could not find acceptable ICU library
|
|||
---|---|---|---|
#18+
Симонов Денис, тогда почему: Код: plsql 1. 2.
возвращает правильное значение UTC для сервера, стоящего на ОС в которой выбран часовой пояс 'Europe/Moscow', при том, что клиент, сделавший SET TIME ZONE 'UTC', на том же самом сервере? Код: plaintext 1. 2. 3. 4. 5.
... |
|||
:
Нравится:
Не нравится:
|
|||
14.06.2019, 10:25 |
|
Firebird 4: Could not find acceptable ICU library
|
|||
---|---|---|---|
#18+
UTC обеспечивает монотонно возрастающую последовательность удобную для сравнений. Технически, в базе лучше хранить именно UTC. Проблема, как я её понимаю: UTC отличается точкой отсчёта от "времени InterBase" - потребуется обновление всех существующих значений времени в полях записей базы или учёт сдвига в зависимости от используемого варианта времени. Локальное время или время в заданном часовом поясе удобно или даже необходимо при работе с литералами. Проблемы, как я их понимаю: 1. Клиент может работать с неверным UTC из-за некорректной установки часового пояса и отсутствия синхронизации с серверами точного времени; 2. Клиент может неверно вычислять смещение от UTC из-за некорректной базы часовых поясов; 3. Эти две проблемы могут комбинироваться. Лично я считаю, что клиент должен передавать на сервер три элемента: 1. UTC, вычисленное клиентом; 2. Смещение локального времени клиента для этого момента UTC; 3. Идентификатор часового пояса на котором клиент делал вычисления. Чтобы не хранить длинные строки идентификаторов часовых поясов предлагается добавить системную таблицу, где будут храниться "код, идентификатор часового пояса". Напомню, на всякий случай, что идентификатор это "Страна/Место" и их может быть сильно больше 256. Таблицу добавить или в security.db (server-wide) или индивидуально в каждую базу. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.06.2019, 10:38 |
|
Firebird 4: Could not find acceptable ICU library
|
|||
---|---|---|---|
#18+
14.06.2019 10:38, Basil A. Sidorov пишет: > Проблема, как я её понимаю: UTC отличается точкой отсчёта от "времени InterBase" - > потребуется обновление всех существующих значений времени в полях записей базы > или учёт сдвига в зависимости от используемого варианта времени. дык тип данных новый, а не старый. старое как жило, так и нехай себе. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
14.06.2019, 13:42 |
|
Firebird 4: Could not find acceptable ICU library
|
|||
---|---|---|---|
#18+
Basil A. SidorovЛично я считаю, что клиент должен передавать на сервер три элемента: 1. UTC, вычисленное клиентом; 2. Смещение локального времени клиента для этого момента UTC; 3. Идентификатор часового пояса на котором клиент делал вычисления.Почему клиент должен корячиться вычисляя UTC, и зачем серверу смещение, вычисленное клиентом (при условии наличия (3)) ? Вот я, как клиент, имею БД, хранящую некоторые события, и записываю, что конференция в Бразилии начнётся 3.08.2019 в 9:00 по местному времени. Накуа я должен при этом вычислять UTC и смещение ? Я хочу положить в БД местное бразильское время и потом получить обратно его же. Как его там внутри будет хранить сервер - мне, как клиенту, до лампочки. Basil A. SidorovЧтобы не хранить длинные строки идентификаторов часовых поясов предлагается добавить системную таблицу, где будут храниться "код, идентификатор часового поясаЭта таблица живёт в данных TZ, и её не нужно тащить в каждую БД. В данный момент её копия есть в коде fbclient. Basil A. Sidorovидентификатор это "Страна/Место" и их может быть сильно больше 256.632 в данный момент. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.06.2019, 13:53 |
|
Firebird 4: Could not find acceptable ICU library
|
|||
---|---|---|---|
#18+
hvladBasil A. SidorovЧтобы не хранить длинные строки идентификаторов часовых поясов предлагается добавить системную таблицу, где будут храниться "код, идентификатор часового поясаЭта таблица живёт в данных TZ, и её не нужно тащить в каждую БД. В данный момент её копия есть в коде fbclient.Дополню - в каждой БД есть системная таблица RDB$TIME_ZONES, показывающая эти данные. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.06.2019, 13:57 |
|
Firebird 4: Could not find acceptable ICU library
|
|||
---|---|---|---|
#18+
hvladВот я, как клиент, имею БД, хранящую некоторые события, и записываю, что конференция в Бразилии начнётся 3.08.2019 в 9:00 по местному времени. Накуа я должен при этом вычислять UTC и смещение ? Я хочу положить в БД местное бразильское время и потом получить обратно его же.Это всё замечательно работает, пока все клиенты в одном часовом поясе. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.06.2019, 14:27 |
|
Firebird 4: Could not find acceptable ICU library
|
|||
---|---|---|---|
#18+
hvladПочему клиент должен корячиться вычисляя UTC Чем это хуже получения UTC из time() и коряченья с результатом localtime()? Вообще, ничто не мешает иметь SQL_LOCALTIMESTAMP_TZ рядом с SQL_TIMESTAMP_TZ и использовать в XSQLVAR.sqltype тот, который больше подходит под имеющиеся (требующиеся) данные. Серверу-то всё равно коерцить хранимое значение. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
14.06.2019, 14:28 |
|
Firebird 4: Could not find acceptable ICU library
|
|||
---|---|---|---|
#18+
Basil A. SidorovhvladВот я, как клиент, имею БД, хранящую некоторые события, и записываю, что конференция в Бразилии начнётся 3.08.2019 в 9:00 по местному времени. Накуа я должен при этом вычислять UTC и смещение ? Я хочу положить в БД местное бразильское время и потом получить обратно его же.Это всё замечательно работает, пока все клиенты в одном часовом поясе.С чего ты взял ? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.06.2019, 14:32 |
|
Firebird 4: Could not find acceptable ICU library
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovhvladПочему клиент должен корячиться вычисляя UTC Чем это хуже получения UTC из time() и коряченья с результатом localtime()?Откуда в моём сценарии выше вообще time() ? Если юзеру нужно текущее время, он с гораздо большей вероятностью использует CURRENT_TIMESTAMP. Но тут речь о другом. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.06.2019, 14:34 |
|
Firebird 4: Could not find acceptable ICU library
|
|||
---|---|---|---|
#18+
hvladBasil A. SidorovЛично я считаю, что клиент должен передавать на сервер три элемента: 1. UTC, вычисленное клиентом; 2. Смещение локального времени клиента для этого момента UTC; 3. Идентификатор часового пояса на котором клиент делал вычисления.Почему клиент должен корячиться вычисляя UTC, и зачем серверу смещение, вычисленное клиентом (при условии наличия (3)) ? Вот я, как клиент, имею БД, хранящую некоторые события, и записываю, что конференция в Бразилии начнётся 3.08.2019 в 9:00 по местному времени. Накуа я должен при этом вычислять UTC и смещение ? Если бы TIMESTAMP хранился на сервере в UTC и также передавался до клиентской библиотеке, то вовсе не обязательно вычислять смещение саомому, так как все нормальные операционные системы имеют у себя актуальную информацию о часовых поясах (если регулярно обновляются) и соответствующие API функции, позволяющие конвертировать LocalTime<->UTC. В винде, например, начиная с Windows 2000: SystemTimeToTzSpecificLocalTime (UTC в локальное) TzSpecificLocalTimeToSystemTime (Локальное в UTC) Перед передачей штампа времени на сервер делаешь TzSpecificLocalTimeToSystemTime, а при получении с сервера - SystemTimeToTzSpecificLocalTime прямо внутри fbclient. Делов-то... ... |
|||
:
Нравится:
Не нравится:
|
|||
14.06.2019, 14:35 |
|
Firebird 4: Could not find acceptable ICU library
|
|||
---|---|---|---|
#18+
rdb_devЕсли бы TIMESTAMP хранился на сервере в UTCОн там хранится в UTC rdb_devи также передавался до клиентской библиотекеНакуа клиенту UTC ? rdb_devтак как все нормальные операционные системы имеют у себя актуальную информацию о часовых поясах (если регулярно обновляются)Вот это вот ЕСЛИ тебя губит. И не надо мне рассказывать про WinApi, я немножко его знаю. В отличие от тебя, показывающего не те ф-ции и не понимающего что в них не так. И если потрудишься таки почитать доку, то узнаешь, что строковые идентификатры регионов в Win ни разу не соответствуют оным в ICU (IANA) ... |
|||
:
Нравится:
Не нравится:
|
|||
14.06.2019, 14:54 |
|
|
start [/forum/topic.php?fid=40&msg=39826343&tid=1560436]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
417ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
66ms |
get tp. blocked users: |
1ms |
others: | 260ms |
total: | 786ms |
0 / 0 |