Опять про даты-время

[Dissident]

Господа, помогите разобраться, уже сломали голову... не можем понять - баг это или мы ламеры.

Суть такова: Есть веб-страничка с редактируемым гридом (размерность Nx8). грид - представление для пользователя, в котором первый столбец - намиенования продуктов из прайс-листа, а первая строка (заголовки столбцов со 2 по 8й) - считаются датами от понедельника текущей недели до воскресенья текущей недели.
В ячейки можно вводить кол-во необходимых продуктов. Таким образом, совокупные данные отдельно взятого столбца передставляют собой спецификацию ЗАКАЗА.
Сия вещь сделана для быстрого приема заказов от клиентов на любой день недели.

Так вот, есть функционал, который при сохранении создает заказ на определенную дату с введенной спецификацией (с помощью стандартного веб-сервиса CRM). Вот как раз с этой датой-временем ЗАКАЗА и происходит странная вещь.
При выполнении данного ф-ла консольным приложением, дата и время становится правильно (т.е. по текущим настройкам клиентского АРМ). При попытке выполнить данный ф-л на сервере (на серверной ASP-странице, под IIS) - с датой-временем происходит интересная вещь. система считает что она находится в часовом поясе Гринвича и добавляет к дате-времени разницу во времени между Грмнвичем и моим часовым поясом.
Мой часовой пояс +5 GMT (Екатеринбург) + учет перехода на летнее время
В итоге при попытке создания заказа после 18-00 местного времени заказы создаются не на дату переданную приложению, а на указанную дату + 6 (5+й летний час) часов.

Попытка создать ЛЮБОЙ объект, передав ему дату приводит к такому же результату.

Да, чтобы избежать уточняющих вопросов и восклицаный "кури RTFM", сразу описываю все сущ. настройки:
1. На клиентских АРМ - WinXP sp3 или Виста, везде часовой пояс +5 GMT
2. На сервере Win2008Server SP1, IIS 7.0, часовой пояс +5 GMT
3. У каждого пользователя CRM в персональных настройках CRM (Рабочая область - Настройка личных параметров - Выбор часового пояса) стоит +5 GMT
4. CRM 4.0 со всеми роллапами, базовый язык Русский

[Dissident]

есть сильные подозрения что портачит IIS
есть ли в нем где-либо настройки, связанные с часовым поясом?

[Bondonello]

может Вам "в лоб" указывать свою зону. В SDK есть описание как работать с timezone.
Сам, к сожалению, не приходилось с таким столкнуться

[Dissident]

Цитата:

может Вам "в лоб" указывать свою зону. В SDK есть описание как работать с timezone.

Дело в том что стадартным методам запроса, создания, модификации как раз и передается дата в UTC формате, т.е. дата, время часовой пояс... сами методы внутри пользуют встроенную функцию конвертации (что-то типа fn_LocalizetUTCTimeZone - эту ф-ю разрыли в описании FilteredSalesOrder и собственно саму ф-ю в описании ф-ий для программирования) и на выходе вываливают в БД значение на 6 часов отстоящее от переданого...

еще раз повторюсь - внутри любого метода вызывается данная ф-я, которая упорно считает что переданный ей параметр соответствует Гринвичу... и начинает применять к ней настройки локальной таймзоны пользователя, от имени которого запущен сервис

[Dissident]

Видимо с детим действительно никто не сталкивался.
ока проблему решили половинчато
1. для IIS указали формат вывода логов родной
2. время явно присваиваем на 12-00 дня. Пока вроде бы обходим эту проблему

[Артем Enot Грунин]

Проблема может быть связана с тем, что для учетных записей под которыми крутятся сервисы системы заданы различные региональные настройки.
Боюсь что у вас крайне специфичная разработка и смоделировать что подобное крайне затруднительно. Совет тут может быть один - дебаггер вам в руки, и ищите где теряются часы.

[Dissident]

Цитата:

Сообщение от Артем Enot Грунин

Проблема может быть связана с тем, что для учетных записей под которыми крутятся сервисы системы заданы различные региональные настройки.
Боюсь что у вас крайне специфичная разработка и смоделировать что подобное крайне затруднительно. Совет тут может быть один - дебаггер вам в руки, и ищите где теряются часы.

у всех учеток одинаковые региональные настройки: +5 GMT Ёбург, Карачи...
это как раз в первую очередь проверяли...
мало того, ручками смотрели в таблички региональных настроек, которые СРМ для себя хранит... там тоже все ОК. Проблему как раз получаем на выходе системной СРМовской ф-ии преобразования даты-времени...