Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 проблема с запросом  [new]
Малрок
Member

Откуда:
Сообщений: 28
Добрый день,

Помогите с решением проблемы.

Используется ms sql server 2000

Есть программа использующая ms sql server 2000 базу данных.

Выполняется запрос к базе данных в обход программы.

Есть поле типа datetime, время там хронится в формате -4 часа от московского.

Каким образом при запросе сделать корректное отображение времени?

Если просто добавить +4 часа, по при переходе на летнее/зимнее время нужно добавлять, удалять один час. При этом старые даты начнут не корректно отображаться.

Каким образом это можно обойти?

Спасибо за помощь.
3 ноя 09, 10:16    [7874776]     Ответить | Цитировать Сообщить модератору
 Re: проблема с запросом  [new]
Glory
Member

Откуда:
Сообщений: 104760
Малрок

Есть поле типа datetime, время там хронится в формате -4 часа от московского.


В sql server 2000 тип datetime не умеет хранить смещение часовых поясов
Т.е. вам придется самому определять алгоритм вычесления тех значений, которые нужны
3 ноя 09, 10:19    [7874795]     Ответить | Цитировать Сообщить модератору
 Re: проблема с запросом  [new]
Малрок
Member

Откуда:
Сообщений: 28
Ну должно быть что-то типа, есть дата в пределах с 1 октября до 1 апреля то +3 часа.
если с 1 апреля до 1 октября, то -4 часа к дате.

Не подскажите как в синтаксе sq это написать?

'CurrentDate' =
CASE
when month(t1.REG_CREATED) between 4 and 4 then dateadd(hour,3,t1.REG_CREATED),
when month(t1.REG_CREATED) between 10 and 3 then dateadd(hour,3,t1.REG_CREATED),
END,

Почему такой вариант не хочет работать?

Спасибо
3 ноя 09, 10:36    [7874930]     Ответить | Цитировать Сообщить модератору
 Re: проблема с запросом  [new]
Glory
Member

Откуда:
Сообщений: 104760
between 10 and 3 - это абсурд. Левое значение должно быть меньше правого
3 ноя 09, 10:42    [7874968]     Ответить | Цитировать Сообщить модератору
 Re: проблема с запросом  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74927
автор
Ну должно быть что-то типа, есть дата в пределах с 1 октября до 1 апреля то +3 часа.
если с 1 апреля до 1 октября, то -4 часа к дате.


Гм... А почему 1.10 и 1.04. Переход на летнее зимнее время осуществляется в последнее воскресенье марта и октября соответственно. Вот этот алгоритм и закодируйте на T-SQL.

автор
Почему такой вариант не хочет работать?


Ну, для начала, хотя бы потому, что

BETWEEN returns TRUE if the value of test_expression is greater than or equal to the value of begin_expression and less than or equal to the value of end_expression

Да и прибавляете Вы в обоих случаях 3 часа.

Сообщение было отредактировано: 3 ноя 09, 10:45
3 ноя 09, 10:44    [7875004]     Ответить | Цитировать Сообщить модератору
 Re: проблема с запросом  [new]
iap
Member

Откуда: Москва
Сообщений: 46975
Судя по всему, на вашем сервере даты хранятся по Гринвичу (UTC), и это очень правильно.
Клиенты, которые обращаются к серверу, могут находиться в любой точке Земли, и поясное
время, а так же правила перехода на летнее время и обратно, определяются в месте расположения клиента.
Но и это ещё не всё. Эти правила иногда меняются. Например, когда-то в Москве переход на летнее время
осуществлялся в жёстко определённый день марта, даже если это был рабочий день. Сейчас - только в воскресенье.

Если Вам нужно определять время по UTC для Москвы с учётом современных правил перехода на летнее время,
то посмотрите, например, здесь
3 ноя 09, 10:51    [7875071]     Ответить | Цитировать Сообщить модератору
 Re: проблема с запросом  [new]
Малрок
Member

Откуда:
Сообщений: 28
iap
Судя по всему, на вашем сервере даты хранятся по Гринвичу (UTC), и это очень правильно.
Клиенты, которые обращаются к серверу, могут находиться в любой точке Земли, и поясное
время, а так же правила перехода на летнее время и обратно, определяются в месте расположения клиента.
Но и это ещё не всё. Эти правила иногда меняются. Например, когда-то в Москве переход на летнее время
осуществлялся в жёстко определённый день марта, даже если это был рабочий день. Сейчас - только в воскресенье.

Если Вам нужно определять время по UTC для Москвы с учётом современных правил перехода на летнее время,
то посмотрите, например, [url=https://www.sql.ru/forum/actualthread.aspx?
bid=1&tid=692428#7611292]здесь[/url]


Спасибо огромное!!!

Очень помогло.
3 ноя 09, 11:26    [7875396]     Ответить | Цитировать Сообщить модератору
 Re: проблема с запросом  [new]
GlebZ
Member

Откуда: USA
Сообщений: 284
iap

Но и это ещё не всё. Эти правила иногда меняются. Например, когда-то в Москве переход на летнее время
осуществлялся в жёстко определённый день марта, даже если это был рабочий день. Сейчас - только в воскресенье.

А у нас вообще волею Буша перенесли на первое воскресенье Ноябрая и не помню. Вроде Апреля.. А парочка штатов вообще послала всё это на ... и часы не переводят. Так что мы эту инфо в базе храним, а по ходу вычисляем. Хотя, на мой взгляд так на клиенте бы это сделать, но уж как сделано, так сделано.
3 ноя 09, 17:34    [7878452]     Ответить | Цитировать Сообщить модератору
 Re: проблема с запросом  [new]
iap
Member

Откуда: Москва
Сообщений: 46975
GlebZ
iap

Но и это ещё не всё. Эти правила иногда меняются. Например, когда-то в Москве переход на летнее время
осуществлялся в жёстко определённый день марта, даже если это был рабочий день. Сейчас - только в воскресенье.

А у нас вообще волею Буша перенесли на первое воскресенье Ноябрая и не помню. Вроде Апреля.. А парочка штатов вообще послала всё это на ... и часы не переводят. Так что мы эту инфо в базе храним, а по ходу вычисляем. Хотя, на мой взгляд так на клиенте бы это сделать, но уж как сделано, так сделано.
Так ведь
Малрок
Есть поле типа datetime, время там хронится в формате -4 часа от московского.
3 ноя 09, 18:04    [7878649]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить