我正在嘗試使用Lotus Java/CORBA類在任意時區創建Domino DateTime對象。使用Lotus Java/CORBA的TimeZone問題session.createDateTime(日曆)
我看起來對於所有具有小時整數倍的基準偏移的時區都是成功的。對於部分時區,特別是像伊朗,印度和斯里蘭卡這樣的半小時區域,或者像尼泊爾那樣不太常見的區域,其時間偏差爲45分鐘。我最終返回一個重新計算爲整數時區的日期時間,例如試圖在伊朗時區(+03:30和1小時DST)中請求18:45,這會給我一個DateTime,代表18:45, +03:00偏移。
這給我帶來了很大的麻煩,因爲它實際上會改變所代表的瞬間,並且導致在將此日期寫入Appointment時,Notes客戶機向用戶解釋日期如何寫入不同的時區。
筆記本身在提供的時區中寫約會沒有問題,雖然它當然是通過不同的連接方式而不是我使用的。
至於細節,我目前使用的是Domino 8.5.1和一個匹配的客戶端,並且已經使用幾個不同版本的NCSO.jar文件來驗證問題。
Java/CORBA類只提供三種創建日期的方法,所有這些方法都在會話對象上。只有其中一種方法被記錄爲時區感知(接受java.util.Calendar對象)。我知道沒有其他方法來創建更新多米諾骨牌時間/日期時間字段所需的日期時間。
記錄DIIOP連接只會產生方法調用模式,下面摘錄的摘錄中詳細介紹了創建DateTime的過程。
先決條件是一個名爲'session'的開放式多米諾會話對象。本次會議的目的是在位於珀斯的UTC + 08:00舉行,以消除它作爲偏斜時間分量的來源。
如果有人在Domino中使用Java/CORBA庫時遇到類似問題,並採取了哪些措施來糾正此問題,我將特別感興趣。或者任何關於我仍然不知道的相關方法的信息,我們都會很感激。
// 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」中產生一個日期,但不幸的是沒有。
以前從未注意到這一點。相當大的遺漏。我不確定全球對伊朗,斯里蘭卡或尼泊爾的時區有什麼影響,但印度是一個巨大的市場,並且在API中有很大的缺陷。我看了一下,看看是否有工作,但目前我無法提出。 – Kerr 2010-07-13 15:29:12