使用LotusJava/CORBA会话的时区问题。createDateTime（日历）

我试图使用LotusJava/CORBA类在任意时区中创建Domino DateTime对象

我似乎在所有时区都取得了成功，这些时区的基本偏移量为整数小时数。对于分数时区，特别是半小时时区，如伊朗、印度和斯里兰卡，或者更不常见的时区，如偏移45分钟的尼泊尔。最后，我得到了一个重新计算为整数时区的DateTime，因此，如果试图请求伊朗时区的18:45（+03:30，DST为1小时），我得到的DateTime表示18:45，偏移量为+03:00

这给我带来了很大的麻烦，因为它实际上改变了所表示的瞬间，并导致在将该日期写入约会时，Notes客户端向用户解释该日期是如何写入不同时区的

Notes本身在提供的时区内书写约会没有问题，尽管它是 这门课程是通过不同的连接实现的，而不是我正在使用的连接

至于细节，我目前正在使用Domino8.5.1和一个匹配的客户机，并使用几个不同版本的NCSO.jar文件验证了这个问题

Java/CORBA类只提供了三种创建日期的方法，它们都在会话对象上。这些方法中只有一种被证明是时区感知的（接受java.util.Calendar对象）。我知道没有其他方法可以创建更新domino Time/DateTime字段所需的DateTime

记录DIIOP连接只会产生方法调用模式，下面的摘录详细介绍了DateTime创建

先决条件是名为“Session”的开放domino会话对象。在本例中，该会话位于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，我认为您不能直接这样做。我不知道为什么需要使用Domino DateTime对象，但是如果需要将值保存到文档中，那么可以使用@formula来解决这个问题

使用

Session.evaluate（字符串公式，文档文档）

在给定文档的上下文中计算公式。这将是您要保存日期时间的文档。您需要将公式构造为字符串，然后将其传入

您需要的公式类似于

字段foo:=@ToTime（“14/07/2010 15:30:00 ZE5C”）

这将把名为

foo的字段设置为指定的日期时间值

因此，您的java调用将如下所示：

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

在文档中保存值后，您必须进行实验以查看返回的值，但更糟糕的情况是，您还必须通过计算@formula来读取值。
我已经解决了这个问题，选择忽略会话。createDateTime（Calendar）方法，因为它的时区行为显然是不正确的

相反，我使用session.createDateTime（Date）在会话时区中创建一个日期，并显式使用dateTime.convertToZone（int，boolean）方法分配所需的区域（改变区域，但不改变时间字段）。这需要手动计算多米诺区域（1表示UTC-01:00，-1表示UTC+01:00，-3005表示UTC+05:30。即，XXYY，其中X表示偏移中整小时过去的分钟数，YY表示偏移中的整数小时数，如果位于本初子午线以东，则整个区域为负数）。您还需要提供一个布尔值，指示给定日期是否在DST中。谢天谢地，通过java.util.TimeZone访问这些信息相当容易

有点麻烦，但至少现在每个人都可以使用自己的本地时间。
以前从未注意到这一点。一个相当大的遗漏。我不确定伊朗、斯里兰卡或尼泊尔的时区问题会对全球产生多大影响，但印度是一个巨大的市场，在API中显示出相当大的缺陷。我看了看是否有解决办法，但目前还没有找到。我尝试了你建议的解决方案，不幸的是@ToTime似乎无法正确处理日期/时间字符串中的区域信息，除了显式命名的区域（CET、EST、MST等）。对于所有ZWx、ZWxy、ZEx和ZExy区域，它将区域信息默认为会话区域（domino服务器本身的区域）。另一个问题是字段公式似乎根本拒绝求值，但用@SetField替换它解决了这个问题。我的答案有点含糊其辞，因为我手头没有设计师来检查它是否正确。很好地捕捉到了@SetField。奇怪的是@ToTime不起作用，它在一个动作按钮中起作用。我不明白为什么它不能通过求值来工作。啊，我想知道如果参数是整数，他们怎么可能这样做。不过很乱。你是怎么知道格式的？我在文件里找不到。也许我只是看得不够仔细。当我在调试器中查看DateTime代理对象的内部状态时，格式对我来说很明显。我怀疑在最初的API设计之后，分数小时时区的支持就被固定了；）与UTC偏移相比，被否定的值使我成为不考虑时间的人。