The BPEL Editor in OpenESB and JavaCAPS 6 offers many utility functoids
(Sun extensions to BPEL).
The DateTime functoid generates a string that conforms to the W3C standard (see section 3.2.7 here)
Whilst this generated string is entirely correct, it's worth noting that the Standard permits variations in structure. This can lead to difficulty when trying to process such data in Java.
I have constructed a utility class that will convert almost any valid W3C DateTime string to a java.util.Date object. [ W3C supports the notion of negative dates. My utility class does not support this because I can't think of a reasonable way to represent such a date using the java.util.Date class. Ideas welcome ] In addition, a further method is provided to convert from java.util.Date to a W3C DateTime that conforms precisely with the style implemented by the aforementioned functoid and which, by definition, conforms to the W3C specification.
Section 3.2.7.1 of the Standard defines in detail the lexical representation of a DateTime object. The main points of interest are that fractions of seconds are optional and, if present, have no maximum length (precision). Also, the timezone offset is optional and when present may take one of two forms. The simplest form is the letter Z (indicating Zulu time). Otherwise it is in the form of ('+'|'-')HH:MM being an offset from Zulu time. Z is equal to +00:00 which is equal to -00:00.
The BPEL functiod emits a string that always has two decimal fractions of seconds and uses the longer form for the timezone offset. This offset is always present.
The utility implementation is in the class com.sun.fast.util.W3CDateTime
Two static methods are of interest:-
java.util.Date toJavaDate(java.lang.String)
and
java.lang.String toW3CDate(java.util.Date)
Here are some examples of valid W3C DateTime strings that can be passed to the toJavaDate method:-
"2009-01-19T15:24:30" // Note the absence of either fractions of seconds or timezone data (Zulu is implied)
"2009-01-19T15:24:30.5" // No timezone
"2009-01-19T15:24:30Z" // Explicit Zulu timezone. No fractions
"2009-01-19T15:24:30.12-01:00" // Fractions to 2 decimal places. Explicit timezone. This is the format generated by the toW3CDate method. The timezone data will be specific to your system's locale.
The utility implementation is available here
The DateTime functoid generates a string that conforms to the W3C standard (see section 3.2.7 here)
Whilst this generated string is entirely correct, it's worth noting that the Standard permits variations in structure. This can lead to difficulty when trying to process such data in Java.
I have constructed a utility class that will convert almost any valid W3C DateTime string to a java.util.Date object. [ W3C supports the notion of negative dates. My utility class does not support this because I can't think of a reasonable way to represent such a date using the java.util.Date class. Ideas welcome ] In addition, a further method is provided to convert from java.util.Date to a W3C DateTime that conforms precisely with the style implemented by the aforementioned functoid and which, by definition, conforms to the W3C specification.
Section 3.2.7.1 of the Standard defines in detail the lexical representation of a DateTime object. The main points of interest are that fractions of seconds are optional and, if present, have no maximum length (precision). Also, the timezone offset is optional and when present may take one of two forms. The simplest form is the letter Z (indicating Zulu time). Otherwise it is in the form of ('+'|'-')HH:MM being an offset from Zulu time. Z is equal to +00:00 which is equal to -00:00.
The BPEL functiod emits a string that always has two decimal fractions of seconds and uses the longer form for the timezone offset. This offset is always present.
The utility implementation is in the class com.sun.fast.util.W3CDateTime
Two static methods are of interest:-
java.util.Date toJavaDate(java.lang.String)
and
java.lang.String toW3CDate(java.util.Date)
Here are some examples of valid W3C DateTime strings that can be passed to the toJavaDate method:-
"2009-01-19T15:24:30" // Note the absence of either fractions of seconds or timezone data (Zulu is implied)
"2009-01-19T15:24:30.5" // No timezone
"2009-01-19T15:24:30Z" // Explicit Zulu timezone. No fractions
"2009-01-19T15:24:30.12-01:00" // Fractions to 2 decimal places. Explicit timezone. This is the format generated by the toW3CDate method. The timezone data will be specific to your system's locale.
The utility implementation is available here