Показать сообщение отдельно
Старый 06.07.2010, 00:01   #7  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5813 (201) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от HorrR Посмотреть сообщение
в наиболее общем виде эту проблему стоило бы решать посредством использования 2 WinApi: RtlLocalTimeToSystemTime и SystemTimeToTzSpecificLocalTime. Трудности в том, что в Аксапте обертки вокруг RtlLocalTimeToSystemTime вообще нет и её нужно создавать. А SystemTimeToTzSpecificLocalTime сделанна таким образом, что преобразование всегда идет в текущую временную зону, то есть для этого метода и для этих целей нужно делать другую обертку.
Не учите людей плохому Во-первых, RtlLocalTimeToSystemTime - это не WinAPI-функция, это внутренняя функция ntdll, интерфейс которой не обязательно будет сохраняться между версиями виндов (вместо нее стоит воспользоваться "настоящей" WinAPI-функцией LocalFileTimeToFileTime), а во-вторых, в 2009-й появился AOS под x64, который не поддерживает DLLFunction в принципе, поэтому такое решение - полумера, не имеющая перспектив в свете обновления на последние версии Аксапты (и поэтому же WinAPIServer в 2009-й переписан на .NET).
Цитата:
Сообщение от HorrR Посмотреть сообщение
Решение же проблемы в конкретном случае оказалось куда более простым. Создаем серверный метод на классе, возвращающий timenow() сервера - имеем серверной время в серверном временном поясе.
По-моему, вы - хотя бы отчасти - скрываете сложность реализации: timenow() выдает число секунд с полуночи. Что, если ваша целевая временнАя зона находится, к примеру, восточнее временнОй зоны сервера? В этом случае вам придется отматывать назад не только время, но и потенциально дату (час ночи 16-го числа в одной зоне может быть десятью вечера 15-го в другой).
За это сообщение автора поблагодарили: Logger (2).