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

[gl00mie]

Те, кто ковырялся в конвертации базы под 2009-ю, могли заметить, что там кроме полей createdDateTime/modifiedDateTime для каждого поля типа UtcDateTime, где значения хранятся по Гринвичу, есть также некое служебное поле, где хранится, условно говоря, идентификатор временной зоны, в которой было введено исходное значение (название этого поля можно узнать, вызвав DictTable.dateTimeTimeZoneRuleFieldName() для поля типа UtcDateTime). Оно в принципе и понятно: глобализация глобализацией, но проводки надо иметь возможность однозначно отнести к тому или иному дню и, соответственно, периоду. Однако, где именно это поле используется в системе? Кроме скриптов конвертации базы и "инструмента исправления часового пояса", ссылок на него я нигде не нашел.

[sukhanchik]

Очевидно - что это поле используется при изменении часового пояса в настройках пользователя. То, что это не вынесено в открытый код, а спрятано в ядре - еще не означает - что это нигде не используется. Но если "запомнить" например дату(время) изменения какой-нибудь записи, затем пойти к себе в настройки и изменить часовой пояс - то повторное обращение к дате изменения - покажет сдвиг на то кол-во часов, на которое отличается новый часовой пояс от старого.

Мне кажется - что одного этого использования уже достаточно.

[gl00mie]

Цитата:

Сообщение от sukhanchik

если "запомнить" например дату(время) изменения какой-нибудь записи, затем пойти к себе в настройки и изменить часовой пояс - то повторное обращение к дате изменения - покажет сдвиг на то кол-во часов, на которое отличается новый часовой пояс от старого. Мне кажется - что одного этого использования уже достаточно.

Дата/время изменения какой-нить записи - это дата/время по Гринвичу, смещенная на нужное число минут в соответствии с настроенным для пользователя часовым поясом. К примеру, винды хранят для файлов т.н. системное время - по Гринвичу, а для пользователя показывают т.н. файловое время (если пользоваться терминологией функций Win32 API). Если пользователь пойдет и поменяет настройку своего часового пояса, то в следующий раз он в виде т.н. файлового времени увидит системное, "сдвинутое" в соответствии с новыми настройками. Тут важны лишь значения системного времени, зафиксированного для какого-то события, и текущей настройки часового пояса, в соответствии с которой надо "сдвинуть" зафиксированное значение при отображении. Зачем в этой ситуации сохранять настройку часового пояса, в котором было зафиксировано исходное событие?
PS. Как раз для даты/времени создания/изменения записей Аксапта настройку часового пояса и не сохраняет.

[sukhanchik]

Цитата:

Сообщение от 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. Как раз для даты/времени создания/изменения записей Аксапта настройку часового пояса и не сохраняет.

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

[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

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

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