Over the past few weeks, I've seen multiple questions related to the DateTime field and time zones with WebSphere Process Server. The question is why does the timezone get normalized in WebSphere Process Server?
The DateTime field in the original message is usually a local timezone set as: <DueDate>2012-03-06T09:43:54.167-06:00</DueDate>
However, after the data passes through WebSphere Process Server, the time is normalized to UTC/GMT/Zulu time. For example: <DueDate>2012-03-06T15:43:54.167Z</DueDate>
The answer to the question is that the XML functionality and XML components that WebSphere Process Server provide, use the convention to always normalize the datetimes value to the UTC/GMT/ZULU timezone. WebSphere Process Server does not provide options to configure specific timezones for its output. The following document describes this issue: http://www.ibm.com/support/docview.wss?uid=swg21503646
Note:: Although the document is written for web services, the same general principles apply to other situations with XML output.
The key point to remember is that the serialization that WebSphere Process Server uses is one of many possible XML messages. However, the value it has chosen is valid and conforms to XML specifications. So, if your destination service conforms to the full XML apecifications, it should be able to understand and treat the DateTime field exactly the same no matter if it is provided in UTC or a local time zone format.
From a logical point of view, any of the time zones still represent the same point in time. It is the same situation as why the numbers "1.0", "1.00" , and "01.0" are all equal in XML.
There are an infinite number of different possible options that you might want related to the format of the XML message, which is beyond the scope of what can be reasonably provided by the product. As other example, we have run across requests for WebSphere Process Server to customize
- The namespace prefixes chosen
- The order of namespace declarations
- The white space tabbing.
Each of these requests for customizations actually reveal a deficiency in the consuming service not being able to fully understand the XML specification and logically equivalent XML messages. Because there are an infinite amount of options, an architectural decision was made to not provide these customization options, but only ensure that we will provide a message that is valid and logically equivalent.
If customization of the message is desired in a specific format, you can use custom code to modify or adjust the message using a custom DataHandler, WebServiceHandler, or other exit point, where you can work with the XML string directly.
Another option is to declare the field as a string, then the value is not normalized to the UTC time zone. Then, you can use the Java Datetime API with the Java String API to produce the desired format.