Зачем нужно поле для хранения временной зоны для значений полей типа UtcDateTime?

[gl00mie]

Цитата:

Сообщение от 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

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

Я лично чем больше думаю об этом, тем больше прихожу к выводу, что дополнительное поле введено только для возможности обновлять настройки перехода на летнее/зимнее время для временных зон после того, как в этих временных зонах были введены те или иные данные.Т.е. допустим, работаем мы в транснациональной компании, и данные у нас вводятся пользователями со всего света. И тут мы узнаем, что в Индии со следующего года тоже решили переходить на зимнее время, а у нас как раз сводное планирование отдано на аутсорсинг в Бангалор и местными сотрудниками уже составлены планы на ближайшие три года. Тогда мы загружаем изменения настроек для соответствующей временной зоны и запускаем какой-нить "Инструмент исправления часового пояса", который перебивает нам уже введенные данные, ссылающиеся на определенный часовой пояс, в соответствии с новыми настройками перехода на летнее/зимнее время для этого пояса.
Во всяком случае, меня на такие мысли наталкивает то, что соответствующие системные поля в стандартном приложении "интересны" лишь буквально паре классов соответствующей направленности.