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