Проблема с датой публикации из-за часовых поясов и использования SystemDateGet()

Создайте функцию в классе Global:

static date systemDateGetLocal()
{
    return DateTimeUtil::date(DateTimeUtil::applyTimeZoneOffset(DateTimeUtil::utcNow(), DateTimeUtil::getUserPreferredTimeZone()));
}

Затем в Info.watchDog() выполните:

systemDateSet(systemDateGetLocal());

Это может быть только частичное решение, watchDog выполняется только на стороне клиента.

Вот быстрое обновление. Дайте мне знать, если есть какие-либо проблемы или ситуации, которые необходимо решить.

ИСПОЛЬЗОВАНИЕ МЕСТНОГО ВРЕМЕНИ

Введение.
Следующее обновление находится в стадии разработки, так как решение еще не полностью протестировано во всех ситуациях.

Проблема.
Если часовой пояс пользователя отличается от часового пояса AOS, функции timeNow() и systemDateGet() возвращают сведения об AOS, когда требуется местная дата и время.

Уточнения:
Когда в Axapta изменяется локальная дата и время, функция systemDateGet() возвращает локальную дату, однако функция timeNow() по-прежнему возвращает время AOS.

Изменения в коде.
Внесен ряд изменений в код для обработки ряда различных ситуаций. Комментарии будут добавлены там, где может потребоваться объяснение.

Скобки были изменены на { и }, чтобы это можно было опубликовать.

КЛАСС: ГЛОБАЛЬНЫЙ

Одно из требований, которое мне было дано, состояло в том, чтобы позволить системе обрабатывать несколько сайтов внутри компании, которые могут иметь разные часовые пояса. В настоящее время эта функция не требуется.

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);
}

КЛАСС: ПРИМЕНЕНИЕ

Измените метод setDefaultCompany. Добавьте строку setSessionDateTime(); сразу после супервызова. Это сделано для того, чтобы время менялось, когда пользователь меняет компанию (еще одно требование, которое мне было дано).

КЛАСС:ИНФО

Чтобы система использовала правильную дату/время с начала сеанса.

void startupPost()
{
    ;
    setSessionDateTime();
}

Измените метод canViewAlertInbox(), добавив строку setSessionDateTime(); в качестве первой строки. Это необходимо, если у пользователя открыто несколько форм для разных компаний.

Изменения, зависящие от локализации:

В зависимости от вашего пакета обновления и локализации вам потребуется изменить функцию объектов, чтобы использовать функцию localTime(), заменив timeNow(). ВАЖНОЕ ПРИМЕЧАНИЕ. Не изменяйте класс BatchRun для использования новой функции localTime, так как это остановит его правильную работу.

В нашей системе было около 260 экземпляров, которые можно было изменить. Если вы не используете все модули и локализации, фактическое количество строк, которые вам нужно изменить, будет меньше.

Последнее примечание:

В коде есть несколько вызовов today(). Я еще не просмотрел каждую строку, чтобы убедиться, что она закодирована правильно, т.е. с использованием today() вместо systemDateGet().

Известные проблемы:

Я столкнулся с ситуацией, когда функция изменения часового пояса не работала полностью, как ожидалось. Это было, когда одна сессия выполняла синхронизацию базы данных, а другая сессия была открыта в другой компании. Поскольку обычные пользователи никогда не смогут этого сделать, я не тратил много времени на ее решение на данном этапе. Это то, что я намерен решить.