TimeZone problems using Lotus Java/CORBA session.createDateTime(Calendar)

Question

I am attempting to create Domino DateTime objects in arbitrary time zones using the Lotus Java/CORBA classes.

I appear to be successful for all time zones which have a base offset which is an integer number of hours. For fractional time zones, notably half-hour ones like Iran, India and Sri Lanka, or even less common ones like Nepal with its 45 minute offset. I end up being returned a DateTime that is recalculated to an integer time zone, such that trying to ask for 18:45 in the Iran time zone (+03:30 with 1 hour DST) gives me a DateTime representing 18:45 with a +03:00 offset.

This causes me significant trouble, as it actually mutates the instant represented, as well as resulting in that when writing this date to an Appointment, the Notes client explains to the user how the date was written in a different time zone.

Notes itself has no problem writing appointments in the provided time zones, although it of course does so through different connectivity than I am utilizing.

As for details, I am currently using Domino 8.5.1 and a matching client, and have verified the problem using several different versions of the NCSO.jar file.

The Java/CORBA classes provide only three methods for creating dates, all of them on the session object. Only one of these methods is documented to be time zone-aware (Accepting a java.util.Calendar object). I am aware of no alternate way to create the DateTime required to update domino Time/DateTime fields.

Logging the DIIOP connection only yields the method call pattern, reproduced below in excerpt detailing the DateTime creation.

Preconditions are an open domino Session object named 'session'. The session is for the purpose of this example located in Perth, at UTC+08:00 to eliminate it as the source of skewed time components.

I would be especially interested in if anyone who uses the Java/CORBA libraries with Domino has encountered similar problems and what course of action was taken to correct this. Alternately any information about relevant methods I remain ignorant of is appreciated.

// 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());

The output and traces from the above code:

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

To clarify the "ZE3" timezone Domino uses this format for a general timezone and it is to be read as "Zone East (positive) offset 03:00". An A, B or C would be suffixed for 15, 30 or 45 minute offsets. The expected offset +03:30 should thus result in a date in zone "ZE3B", but unfortunatly doesn't.

Answer 1

Looking at the API I don't think that you are going to be able to do this directly. I'm not sure why you need Domino DateTime objects to work with, but if what you need to do is save the values on a document then you can work around this by using @formula.

Use Session.evaluate(String formula, Document doc) to evaluate fomula in the context of a given document. This will be the document that you want to save date time to. You will need to construct the formula as a String and then pass it in.

The formula you need would look something like FIELD foo:=@ToTime("14/07/2010 15:30:00 ZE5C") This will set the field named foo to the DateTime value specified.

So your java call will look something like this:

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

You will have to experiment to see what values you get back once you have the value saved on the document, but worse case scenario is that you will have to read the values via evaluating @formula as well.

Answer 2

I have worked around this issue by electing to ignore the session.createDateTime(Calendar) method entirely, as it's timeZone behaviour is apparently incorrect.

Instead I use session.createDateTime(Date) to create a date in the session timezone and explicitly use the dateTime.convertToZone(int, boolean) method to assign the required zone (mutates the zone, but not the time fields). This requires calculating the domino zone manually (1 for UTC-01:00, -1 for UTC+01:00, -3005 for UTC+05:30. ie, XXYY where X is the minutes past the whole hour in the offset, YY is the integer hours in the offset, and the entire zone is negated if it's east of the prime meridian). You also need to provide a boolean indicating if the given date is in DST or not. This information is thankfully fairly easy to access through java.util.TimeZone.

A bit cumbersome, but atleast now everyone can use their own local time.