AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Функционал
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 27.11.2010, 19:41   #1  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
? Зачем нужно поле для хранения временной зоны для значений полей типа UtcDateTime?
Те, кто ковырялся в конвертации базы под 2009-ю, могли заметить, что там кроме полей createdDateTime/modifiedDateTime для каждого поля типа UtcDateTime, где значения хранятся по Гринвичу, есть также некое служебное поле, где хранится, условно говоря, идентификатор временной зоны, в которой было введено исходное значение (название этого поля можно узнать, вызвав DictTable.dateTimeTimeZoneRuleFieldName() для поля типа UtcDateTime). Оно в принципе и понятно: глобализация глобализацией, но проводки надо иметь возможность однозначно отнести к тому или иному дню и, соответственно, периоду. Однако, где именно это поле используется в системе? Кроме скриптов конвертации базы и "инструмента исправления часового пояса", ссылок на него я нигде не нашел.
Старый 27.11.2010, 20:32   #2  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,271 / 3465 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Очевидно - что это поле используется при изменении часового пояса в настройках пользователя. То, что это не вынесено в открытый код, а спрятано в ядре - еще не означает - что это нигде не используется. Но если "запомнить" например дату(время) изменения какой-нибудь записи, затем пойти к себе в настройки и изменить часовой пояс - то повторное обращение к дате изменения - покажет сдвиг на то кол-во часов, на которое отличается новый часовой пояс от старого.

Мне кажется - что одного этого использования уже достаточно.
__________________
Возможно сделать все. Вопрос времени
Старый 28.11.2010, 00:47   #3  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
если "запомнить" например дату(время) изменения какой-нибудь записи, затем пойти к себе в настройки и изменить часовой пояс - то повторное обращение к дате изменения - покажет сдвиг на то кол-во часов, на которое отличается новый часовой пояс от старого. Мне кажется - что одного этого использования уже достаточно.
Дата/время изменения какой-нить записи - это дата/время по Гринвичу, смещенная на нужное число минут в соответствии с настроенным для пользователя часовым поясом. К примеру, винды хранят для файлов т.н. системное время - по Гринвичу, а для пользователя показывают т.н. файловое время (если пользоваться терминологией функций Win32 API). Если пользователь пойдет и поменяет настройку своего часового пояса, то в следующий раз он в виде т.н. файлового времени увидит системное, "сдвинутое" в соответствии с новыми настройками. Тут важны лишь значения системного времени, зафиксированного для какого-то события, и текущей настройки часового пояса, в соответствии с которой надо "сдвинуть" зафиксированное значение при отображении. Зачем в этой ситуации сохранять настройку часового пояса, в котором было зафиксировано исходное событие?
PS. Как раз для даты/времени создания/изменения записей Аксапта настройку часового пояса и не сохраняет.
Старый 28.11.2010, 10:55   #4  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,271 / 3465 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от gl00mie Посмотреть сообщение
Дата/время изменения какой-нить записи - это дата/время по Гринвичу, смещенная на нужное число минут в соответствии с настроенным для пользователя часовым поясом. К примеру, винды хранят для файлов т.н. системное время - по Гринвичу, а для пользователя показывают т.н. файловое время (если пользоваться терминологией функций Win32 API). Если пользователь пойдет и поменяет настройку своего часового пояса, то в следующий раз он в виде т.н. файлового времени увидит системное, "сдвинутое" в соответствии с новыми настройками.
По ходу дела - АХ теперь также делает. Только без учета часового пояса пользователя.

Цитата:
Сообщение от gl00mie Посмотреть сообщение
Тут важны лишь значения системного времени, зафиксированного для какого-то события, и текущей настройки часового пояса, в соответствии с которой надо "сдвинуть" зафиксированное значение при отображении. Зачем в этой ситуации сохранять настройку часового пояса, в котором было зафиксировано исходное событие?
А ... понял. Я, находясь в Москве (у меня в настройках часового пояса стоит Москва) - изменил запись в 14:34. Система зафиксировала - 14:34.
Другой человек, находясь в Уфе (мск+2 часа) (точнее у него в настройках часового пояса стоит Уфа) видит - что я изменил запись в 16:34. Это достигается тем, что к времени, которое хранится в БД по Гринвичу прибавляется часовой пояс пользователя.
И теперь вопрос - зачем хранить информацию, что запись была сделана пользователем с часовым поясом Москва?
Ответ (исключительно мое мнение без какого либо документального подтверждения). Если строить запросы к БД "снаружи" (Reporting Services, OLAP) - то без информации о часовом поясе нельзя будет четко понять - а сколько же было времени (там же нет текущего пользователя АХ). Тот же бизнес-коннектор (если использовать его) - заходит всегда в АХ под одним и тем же пользователем. А на портал, который заходит в АХ через бизнес-коннектор заходить могут люди из разных часовых поясов.
Пример. Я (Москва) изменил запись в 14:34. Уфимец - в 16:38. Сохранится время - 11:34 и 11:38. При построении отчета в Reporting Services - отчет будет собираться на сервере (который находится например, в Ташкенте +4 часа). А на отчет будут смотреть несколько пользователей из разных часовых поясов и все увидят ташкентское время (или время по Гринвичу, неприведенное к их поясу), что неправильно.
Кстати - надо будет посмотреть как это все будет работать.

Цитата:
Сообщение от gl00mie Посмотреть сообщение
PS. Как раз для даты/времени создания/изменения записей Аксапта настройку часового пояса и не сохраняет.
Ну вот это видимо сделано так, потому что наверное не предполагается делать запросы по этим полям извне.
__________________
Возможно сделать все. Вопрос времени

Последний раз редактировалось sukhanchik; 28.11.2010 в 11:02.
Старый 28.11.2010, 19:58   #5  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Если строить запросы к БД "снаружи" (Reporting Services, OLAP) - то без информации о часовом поясе нельзя будет четко понять - а сколько же было времени (там же нет текущего пользователя АХ).
А зачем нужно понимать, сколько показывали часы по местному времени, глядя в отчеты? Кроме того, за OLAP не скажу, а для SSRS как раз-таки сделаны завязки на "текущего пользователя AX", см., например, Интеграция с Reporting Services в 4.0, ужасы SysSRSTablePermissions. С точки зрения отчетности стоит учесть также тот факт, что полностью доверять информации о той временной зоне, в которой якобы работает пользователь, вводящий данные, нельзя, потому что он может произвольно менять соответствующую настройку.
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Тот же бизнес-коннектор (если использовать его) - заходит всегда в АХ под одним и тем же пользователем. А на портал, который заходит в АХ через бизнес-коннектор заходить могут люди из разных часовых поясов.
Для того, чтобы определить, в какой часовой пояс конвертировать те или иные значения даты/времени для отображения в текущей сессии, не обязательно уметь сопоставлять пользователя, который зашел на портал, и пользователя в Аксапте с его настройкой временной зоны по умолчанию. К примеру, движок этого форума вполне справляется с этой задачей и даже автоматически меняет настройки в профиле в зависимости от того, какая при заходе на форум настроена временная зона (как минимум это верно для перехода на летнее/зимнее время).
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Пример. Я (Москва) изменил запись в 14:34. Уфимец - в 16:38. Сохранится время - 11:34 и 11:38. При построении отчета в Reporting Services - отчет будет собираться на сервере (который находится например, в Ташкенте +4 часа). А на отчет будут смотреть несколько пользователей из разных часовых поясов и все увидят ташкентское время (или время по Гринвичу, неприведенное к их поясу), что неправильно.
И как же в описанном сценарии информация о том, в каком часовом поясе какая проводка введена, поможет пользователям из разных часовых поясов, которые будут смотреть отчет?
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Ну вот это видимо сделано так, потому что наверное не предполагается делать запросы по этим полям извне.
Я лично чем больше думаю об этом, тем больше прихожу к выводу, что дополнительное поле введено только для возможности обновлять настройки перехода на летнее/зимнее время для временных зон после того, как в этих временных зонах были введены те или иные данные.Т.е. допустим, работаем мы в транснациональной компании, и данные у нас вводятся пользователями со всего света. И тут мы узнаем, что в Индии со следующего года тоже решили переходить на зимнее время, а у нас как раз сводное планирование отдано на аутсорсинг в Бангалор и местными сотрудниками уже составлены планы на ближайшие три года. Тогда мы загружаем изменения настроек для соответствующей временной зоны и запускаем какой-нить "Инструмент исправления часового пояса", который перебивает нам уже введенные данные, ссылающиеся на определенный часовой пояс, в соответствии с новыми настройками перехода на летнее/зимнее время для этого пояса.
Во всяком случае, меня на такие мысли наталкивает то, что соответствующие системные поля в стандартном приложении "интересны" лишь буквально паре классов соответствующей направленности.
За это сообщение автора поблагодарили: Logger (3).
Теги
ax2009, utcdatetime, временная зона

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Сохранение значений полей после ошибки ahtoh DAX: Программирование 8 20.06.2008 13:32
Поле типа Время, как отображать время > 24:00? valentino DAX: Программирование 2 04.04.2007 16:58
Как получить значения полей (modifiedDate, modifiedTime, modifiedBy и др.) при работе с объектами AOT типа Map? LRA DAX: База знаний и проекты 15 02.04.2007 13:37
Ссылка на поле другого типа Gorlum DAX: Программирование 2 08.06.2005 17:27
Объединить несколько полей таблицы в одном поле Grid-а на форме? storer DAX: Программирование 2 12.11.2003 14:08
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 07:58.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.