Вот быстрое обновление.Сообщите мне, если есть какие-либо проблемы или ситуации, которые необходимо устранить.
ИСПОЛЬЗОВАНИЕ МЕСТНОГО ВРЕМЕНИ
Введение:
Ниже приведено обновление в процессе разработки, поскольку решение еще предстоит полностью протестировать во всех ситуациях.
Проблема:
Если у пользователя другой часовой пояс, чем у AOS, timeNow () и systemDateGet () функции возвращают детали AOS, когда требуется местное время.
Уточнители:
Когда местное время даты изменяется в Axapta, функция systemDateGet () возвращает локальную дату, однако функция timeNow () по-прежнему возвращает время AOS.
Изменения кодирования:
Был внесен ряд изменений кодирования для обработки ряда различных ситуаций.Комментарии могут быть добавлены в тех случаях, когда может потребоваться объяснение.
Скобки были изменены на {и}, чтобы это можно было опубликовать.
КЛАСС: ГЛОБАЛЬНЫЙ
Одно требование Iбыло дано, чтобы позволить системе обрабатывать несколько сайтов внутри компании, которые могут иметь разные часовые пояса.В настоящее время эта функциональность не требуется.
static server void setSessionDateTime(
inventSiteId inventSiteId = '',
utcDateTime reference = dateTimeUtil::utcNow())
{
str sql;
sqlStatementExecutePermission perm;
connection conn = new UserConnection();
timeZone timeZone;
int ret;
;
if (inventSiteId)
{
timeZone = inventSite::find(inventSiteId).Timezone;
}
else
{
timeZone = dateTimeUtil::getCompanyTimeZone();
}
//This is to get around the kernel validation of changing timezones
//when the user has more than one session open.
sql = strfmt("Update userInfo set preferredTimeZone = %1 where userInfo.id = '%2'", enum2int(timeZone), curUserId());
perm = new SQLStatementExecutePermission(sql);
perm.assert();
ret = conn.createStatement().executeUpdate(sql);
dateTimeUtil::setUserPreferredTimeZone(timeZone);
dateTimeUtil::setSystemDateTime(reference);
CodeAccessPermission::revertAssert();
}
static int localTime()
{
utcDateTime tmp;
;
setSessionDateTime();
tmp = dateTimeUtil::applyTimeZoneOffset( dateTimeUtil::utcNow(), dateTimeUtil::getCompanyTimeZone());
return dateTimeUtil::time(tmp);
}
Следующий метод был реализован как перекрестная проверка, чтобы гарантировать, что systemDateGet() возвращает ожидаемое значение.
static date localDate()
{
utcDateTime tmp;
;
setSessionDateTime();
tmp = dateTimeUtil::applyTimeZoneOffset( dateTimeUtil::utcNow(), dateTimeUtil::getCompanyTimeZone());
return dateTimeUtil::date(tmp);
}
CLASS: APPLICATION
Изменить метод setDefaultCompany.Добавьте строку setSessionDateTime(); сразу после супер звонка.Это позволяет изменить время, когда пользователь меняет компанию (другое требование, которое мне было дано).
CLASS: INFO
, чтобы система использовала правильную дату / время с началасеанс.
void startupPost()
{
;
setSessionDateTime();
}
Измените метод canViewAlertInbox(), добавив строку setSessionDateTime(); в качестве первой строки.Это необходимо, если у пользователя есть несколько форм, открытых для разных компаний.
Изменения, зависящие от локализации:
В зависимости от вашего пакета обновления и локализаций, вам нужно будет изменитьфункция объектов, чтобы использовать функцию localTime (), заменяя timeNow ().ВАЖНОЕ ПРИМЕЧАНИЕ. Не изменяйте класс BatchRun для использования новой функции localTime, так как это приведет к неправильной работе.
В нашей системе насчитывалось около 260 экземпляров, которые можно было изменить.Если вы не используете все модули и локализации, фактическое количество строк, которое вам нужно изменить, будет меньше.
Итоговое примечание:
На сегодняшний день существует ряд () звонки в коде.Я еще не прошел каждую строку, чтобы убедиться, что она закодирована правильно, то есть с использованием today () вместо systemDateGet ().
Известные проблемы:
Я столкнулся с ситуацией, когда функция изменения часового пояса не работала полностью, как ожидалось.Это было, когда один сеанс выполнял синхронизацию базы данных, а другой был открыт в другой компании.Поскольку обычные пользователи никогда не смогут сделать это, я не потратил много времени на его решение на данном этапе.Это то, что я собираюсь решить.