Проблемы с часовым поясом при использовании Lotus Java / CORBA session.createDateTime (Calendar)

Question

Я пытаюсь создать объекты Domino DateTime в произвольных часовых поясах, используя классы Lotus Java / CORBA.

Кажется, я успешен для всех часовых поясов с базовым смещением, которое представляет собой целое число часов.Для дробных часовых поясов, особенно получасовых, таких как Иран, Индия и Шри-Ланка, или даже менее распространенных, таких как Непал с его 45-минутным смещением.В итоге мне возвращают DateTime, который пересчитывается в целочисленный часовой пояс, так что при попытке запросить 18:45 в часовом поясе Ирана (+03: 30 с 1 часом летнего времени) мне присваивается DateTime, представляющий 18:45 с+03: 00 смещение.

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

У самой Notes нет проблем с записью встреч в предоставленных часовых поясах, хотя, конечно, это происходит с помощью подключения, отличного от используемого мной.

Что касается деталей, в настоящее время я использую Domino 8.5.1 и соответствующего клиента, и проверили проблему, используя несколько разных версий файла NCSO.jar.

Классы Java / CORBA предоставляют только три метода для создания дат, все они в объекте сеанса.Только один из этих методов задокументирован для учета часовых поясов (Принятие объекта java.util.Calendar).Я не знаю альтернативного способа создания DateTime, необходимого для обновления полей Time / DateTime в домино.

Ведение журнала соединения DIIOP дает только шаблон вызова метода, воспроизведенный ниже в выдержке, подробно описывающей создание DateTime.

Предварительными условиями является открытый объект Session с именем «сессия».Для целей этого примера этот сеанс расположен в Перте, в UTC + 08: 00, чтобы исключить его как источник искаженных временных составляющих.

Мне было бы особенно интересно, если бы кто-нибудь, кто использует Java / CORBAбиблиотеки с Domino столкнулись с похожими проблемами, и какие действия были предприняты, чтобы исправить это.С другой стороны, любая информация о соответствующих методах, о которых я остаюсь в неведении, ценится.

// first block creates a Calendar for 2010-07-21T10:15:00 in the Iran time zone.
// so far, nothing domino specific. The resulting calendar is verified as correct.

TimeZone tz = TimeZone.getTimeZone("Asia/Tehran");
Calendar calendar = Calendar.getInstance(tz);
calendar.setTimeZone(tz);
calendar.set(2010, 6, 21, 10, 15, 0);

// first call
DateTime result = session.createDateTime(calendar);

// second call
System.out.println(result.getTimeZone());

// third call
System.out.println(result.getZoneTime());

Вывод и следы из приведенного выше кода:

first call to Domino produces the following DIIOP trace 
2010-07-12 23:22:28   DIIOP Session SN000472537: Executing createDateTimeObject 
2010-07-12 23:22:28   DIIOP Session SN000472537: Executing setZoneDateTimeFromJava 
2010-07-12 23:22:29   DIIOP Session SN000472537: Executing getDateTime


second call to Domino, on the resulting DateTime object to retrieve the integer offset. We expect -3003, which is how Domino encodes 03:30 east of the prime meridian. Instead we recieve -3, which encodes 03:00 east of the prime meridian.

second call to Domino produces the following trace 
2010-07-12 23:22:58   DIIOP Session SN000472537: Executing getDateTime

second call produces the following stdout output
-3

third call to Domino to retrieve the printable time as Domino knows it.

third call produces the following DIIOP trace. 
2010-07-12 23:23:14   DIIOP Session SN000472537: Executing getZoneTime 
2010-07-12 23:23:14   DIIOP Session SN000472537: Executing getDateTime

third call results in the following stdout output 2010-07-21 10:15:00 ZE3

Чтобы уточнить часовой пояс "ZE3", Domino использует этоформат для общего часового пояса, и его следует читать как «Зона Восток (положительное) смещение 03:00».A, B или C будут суффиксированы для 15, 30 или 45 минутных смещений.Таким образом, ожидаемое смещение +03: 30 должно привести к дате в зоне "ZE3B", но, к сожалению, это не так.

Answer 1

Я обошел эту проблему, решив полностью игнорировать метод session.createDateTime (Calendar), так как его поведение timeZone явно некорректно.

Вместо этого я использую session.createDateTime (Date) для создания датыв часовом поясе сеанса и явно используйте метод dateTime.convertToZone (int, boolean) для назначения требуемой зоны (изменяет зону, но не поля времени).Для этого требуется вычислить зону домино вручную (1 для UTC-01: 00, -1 для UTC + 01: 00, -3005 для UTC + 05: 30. Т. Е. XXYY, где X - минуты после целого часа в смещении,YY - целое число часов в смещении, и вся зона отрицается, если она находится к востоку от основного меридиана).Вы также должны предоставить логическое значение, указывающее, указана ли указанная дата в летнее время или нет.К этой информации, к счастью, довольно легко получить доступ через java.util.TimeZone.

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

Answer 2

Глядя на API, я не думаю, что вы сможете сделать это напрямую.Я не уверен, зачем вам нужны объекты Domino DateTime, но если вам нужно сохранить значения в документе, то вы можете обойти эту проблему, используя @ формулу.

Использование Session.evaluate(String formula, Document doc)оценить формулу в контексте данного документа.Это будет документ, в который вы хотите сохранить дату и время.Вам нужно будет создать формулу в виде строки и затем передать ее.

Необходимая формула будет выглядеть примерно так: FIELD foo:=@ToTime("14/07/2010 15:30:00 ZE5C") Это установит поле с именем foo в указанное значение DateTime.

Таким образом, ваш Java-вызов будет выглядеть примерно так:

String dateString="14/07/2010 15:30:00 ZE5C";
session.evaluate("@SetField(\"foo\";@ToTime(\""+dateString+"\"))", doc);
doc.save();

Вам придется поэкспериментировать, чтобы увидеть, какие значения вы получите, когда вы сохраните значение в документе, но в худшем случаечто вам придется читать значения через оценку @formula.