| Author |
Message
|
| protocol7 |
 Posted: Fri Nov 16, 2007 3:36 am Post subject: Time zone support in the WMB Java API |
 |
|
Novice
Joined: 27 Nov 2003
Posts: 13
Location: Göteborg, Sweden
|
Hi
As is very well documented in the MbTimestamp and MbTime classes, they do not support working with time zones. In my tests, WMB will silently drop any time zone information it has in the parsed tree from the Java classes. That means that if I sent a time looking like 12:00:00+03:00 I will in my MbTime instance get the time 12:00:00 and my local time zone. This is not exactly what you would want 
Does anyone know a way around this? Currently, in our helper classes (http://wmb-util.googlecode.com) we have an option to parse the time as a string and then let Java parse the time using SimpleDateFormat. But, this feels a bit awkward given that the parser really should offer this for us.
WMB obviously retain knowledge of the time zone in the parsed tree as it will correctly set it in the output message if you make a simple MQInput -> MQOutput flow with a message set parsing a time in the incoming message. It just seems not to allow access to it in the APIs.
If using the MRM parser for XML messages, you would kind of expect it to follow the ISO 8601 rules that xs:dateTime uses. But without time zones that would be hard :-/
/niklas |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Fri Nov 16, 2007 3:55 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
You are concerned about time zones...
Why not work with GMTTimestamp then? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Nov 16, 2007 4:25 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Cool project. I'll have to look at it in more detail.
You should provide ESQL definitions to call your classes from ESQL, too.
There isn't, unfortunately, an MbGMTTimestamp class.
The message parsers don't have anything to do with this - this is about the API and the mapping between Java and ESQL data types.
I don't know that there's anything you can do about this, other than see if it's "fixed" in 6.1.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| protocol7 |
| Posted: Fri Nov 16, 2007 4:35 am Post subject: |
|
|
Novice
Joined: 27 Nov 2003
Posts: 13
Location: Göteborg, Sweden
|
Thanks! Please have a look. Any feedback is welcome Feel free to email me directly at niklas@protocol7.com if you want to discuss it further.
Supporting ESQL is not that high on my priority list, but if you or anyone else would like to provide it, I would be happy to add it or give commit access.
According to the documentation, MbTimestamp and MbTime should support UTC (as the only timezone they support), which I guess mean that they get that for free by not supporting time zones at all What would really be needed is for the Java API not to emulate ESQL but instead support to standard Java classes, like Calendar in this case.
I'll have a look at 6.1 and see if any work has been done in this area.
/niklas |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Nov 16, 2007 4:46 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| WMB obviously retain knowledge of the time zone in the parsed tree as it will correctly set it in the output message if you make a simple MQInput -> MQOutput flow with a message set parsing a time in the incoming message. |
WMB does not store the time zone offset in the parsed tree - unless you are using the MRM domain. If the message flow has not modified the message tree, WMB simply outputs the original bitstream - so that's why your MQInput -> MQOutput scenario appears to work. |
|
| Back to top |
|
|
| protocol7 |
| Posted: Fri Nov 16, 2007 5:02 am Post subject: |
|
|
Novice
Joined: 27 Nov 2003
Posts: 13
Location: Göteborg, Sweden
|
| kimbert wrote: |
| WMB does not store the time zone offset in the parsed tree - unless you are using the MRM domain. If the message flow has not modified the message tree, WMB simply outputs the original bitstream - so that's why your MQInput -> MQOutput scenario appears to work. |
Yes, I should have noted that I was using the MRM tree. Although, I guess that's the only place where something would be a typed time/timestamp rather than plain text
In the case of MRM, even if changing other parts of the tree (and not the timestamp), the same time zone as parsed is serialized in the output message. But, this is just an indication that the parser actually cares about time zones, albeit the API does seem to.
/niklas |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Nov 16, 2007 5:20 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
And finally as a work around you can treat the fields as plain text instead of timestamps and use pure old java with Calendar and formatters to parse and serialize ... your timestamps.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| protocol7 |
| Posted: Fri Nov 16, 2007 5:27 am Post subject: |
|
|
Novice
Joined: 27 Nov 2003
Posts: 13
Location: Göteborg, Sweden
|
| fjb_saper wrote: |
| And finally as a work around you can treat the fields as plain text instead of timestamps and use pure old java with Calendar and formatters to parse and serialize ... your timestamps. |
Yes, that is exactly what we're currently doing. You can find the code in the getDateField(String name, String datePattern) method:
http://wmb-util.googlecode.com/svn/wmb-util/trunk/src/main/java/com/googlecode/wmbutil/messages/TdsRecord.java
I have some issues with this approach:
* we don't get validation but instead get the error from our Java code
* the Java code is tightly bound to the physical format. A nice property with the MRM parser is that you can have different physical formats and the same logical tree.
/niklas |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Nov 16, 2007 5:43 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I was thinking of just using the patterns for all your date timestamps :
like "yyyy-mm-ddThh:mm:ss.SSSSSSZZZ" or something like it.
So you do not have to worry about the pattern because it is the same on 90% of your messages. Exceptions would get funnelled through a flow to standardize Timestamps first....
I understand that you may need to adopt a different approach if you have to deal with wide range of date and timestamp patterns 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| protocol7 |
| Posted: Fri Nov 16, 2007 5:51 am Post subject: |
|
|
Novice
Joined: 27 Nov 2003
Posts: 13
Location: Göteborg, Sweden
|
| fjb_saper wrote: |
| I understand that you may need to adopt a different approach if you have to deal with wide range of date and timestamp patterns |
Yeah, handling all kinds of different formats is pretty much the reason why we use WMB
/niklas |
|
| Back to top |
|
|
|
|
