WebSphere Message Broker, Version 8.0.0.7 Operating Systems: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

See information about the latest product version

Representation of ESQL datetime data types

When your application sends a message to a broker, the way in which the message data is interpreted depends on the content of the message itself and the configuration of the message flow. If your application sends a message to be interpreted either by the generic XML parser, or the MRM parser, that is tailored by an XML physical format, the application can include date or time data that is represented by any of the XML Schema primitive datetime data types.

The XML Schema data type of each piece of data is converted to an ESQL data type, and the element that is created in the logical message tree is of the converted type. If the datetime data in an input message does not match the rules of the chosen schema data type, the values that the parser writes to the logical message tree are modified even if the message is in the MRM domain and you have configured the message flow to validate the input message. (Validation is not available for generic XML messages.)

This has the following effect on the subfields of the input datetime data:

The following examples illustrate these points.

Input data XML Schema data type Schema rules Input value in the bit stream Value written to the logical tree (ESQL data type in brackets)
xsd:dateTime CCYY-MM-DDThh:mm:ss 2002-12-31T23:59:59 2002-12-31 23:59:59 (TIMESTAMP)
    --24 1970-01-24 (DATE)
    23:59:59 23:59:59 (TIME)
xsd:date CCYY-MM-DD 2002-12-31 2002-12-31 (DATE)
    2002-12-31T23:59:59 2002-12-31 (DATE)
    -06-24 1970-06-24 (DATE)
xsd:time hh:mm:ss 14:15:16 14:15:16 (TIME)
xsd:gDay ---DD ---24 1970-01-24 (DATE)
xsd:gMonth --MM --12 1970-12-01 (DATE)
xsd:gMonthDay --MM-DD --12-31 1970-12-31 (DATE)
xsd:gYear CCYY 2002 2002-01-01 (DATE)
xsd:gYearMonth CCYY-MM 2002-12 2002-12-01 (DATE)

Validation with missing subfields

When you consider which schema datetime data type to use, consider that, if the message is in the MRM domain, and you configure the message flow to validate messages, missing subfields can cause validation exceptions.

The schema data types Gday, gMonth, gMonthDay, gYear, and gYearMonth are used to record particular recurring periods of time. There is potential confusion when validation is turned on, because the recurring periods of time that are used in these schema data types are stored by ESQL as specific points in time.

For example, when the 24th of the month, which is a gDay (a monthly day) type, is written to the logical tree, the missing month and year subfields are supplied from the epoch (January 1970) to provide the specific date 1970-01-24. If you code ESQL to manipulate this date, for example by adding an interval of 10 days, and then generate an output message that is validated, an exception is raised. This is because the result of the calculation is 1970-02-03 which is invalid because the month subfield of the date no longer matches the epoch date.

Use within an MRM domain

In MRM it is possible to define an element that has the logical type of dateTime.

When a dateTime element is parsed, a field is created in the message tree that has the ESQL datatype of CURRENT_TIME or CURRENT_TIMESTAMP. However, the CURRENT_TIME and CURRENT_TIMESTAMP data types do not have the functionality to store timezone information, and the MRM does not adjust the time according to the input timezone and the timezone of the broker.

Although the CURRENT_TIME and CURRENT_TIMESTAMP data types cannot store timezone information, the MRM stores this information as part of the underlying field. This means that if the field is copied between message trees, the timezone information is copied with it, allowing this information to be preserved on output.

Note that the information is preserved only if the field is copied to a field of the same name.

However, if any new field is derived from the original field, the new field does not have the timezone information. This means that if such a field is cast as a character, the new field assumes the timezone of the broker, but its value is not adjusted for any difference between the input timezone and the timezone of the broker.

For example, an input dateTime element containing 2009-02-20T06:08:07-08:00 could be copied from the input message tree to the output message tree and appear in an output message in exactly the same format. However, if the element is cast as character, using format IU, by a broker running GMT the result would be 2009-02-20T06:08:07.000Z.

Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 1999, 2016Copyright IBM Corporation 1999, 2016.

        
        Last updated:
        
        Last updated: 2016-05-23 14:47:09


Concept topicConcept topic | Version 8.0.0.7 | ak01005_