Author |
Message
|
j.f.sorge |
Posted: Wed Oct 19, 2011 5:15 am Post subject: timezone mismatch in MRM on dateTime & time |
|
|
Master
Joined: 27 Feb 2008 Posts: 218
|
We're running WMB 6.1.0.9 on solaris and have imported a XML schema file into a message set which contains CWF definition, too. We are using MRM parser to validate and parse both CWF and XML fomat.
When reading the CWF dateTime format we're using the following format yyyy-MM-dd-HH.mm.ss.SSSSSS.
Code: |
XGWEH01_TIMESTAMP = TIMESTAMP '2011-07-29 13:54:28.907425' (TIMESTAMP) |
After the value has been mapped into XML it will be written with format IU.
Code: |
SendingTimestamp = TIMESTAMP '2011-07-29 13:54:28.907425' (TIMESTAMP) |
When looking at the XML output message it results in 2011-07-29T13:54:28.907+02:00 which seems to be okay for MEST.
But when reading the CWF time format we're using the following format HHmmss.
Code: |
XGUSQ01_ABSCHLUSS_ZEIT = TIME '09:11:57' (TIME) |
After the value has been mapped into XML it will be written with format TU.
Code: |
abschlussZeit = TIME '09:11:57' (TIME) |
When looking at the XML output message it results in 09:11:57+01:00 which is NOT okay for MEST.
Does anyone have an idea why timezones mismatch within the same message? _________________ IBM Certified Solution Designer - WebSphere MQ V6.0
IBM Certified Solution Developer - WebSphere Message Broker V6.0
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
Back to top |
|
 |
lancelotlinc |
Posted: Wed Oct 19, 2011 5:32 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
Any storage or computation of time values should always be in Zulu (GMT). You should never store or compute time values with reference to time zones.
Your examples have times that seem to come from different messages. It would help to explain your problem by using the value from the same message. _________________ http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
Back to top |
|
 |
mqjeff |
Posted: Wed Oct 19, 2011 5:37 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
|
Back to top |
|
 |
j.f.sorge |
Posted: Wed Oct 19, 2011 7:27 am Post subject: |
|
|
Master
Joined: 27 Feb 2008 Posts: 218
|
lancelotlinc wrote: |
Any storage or computation of time values should always be in Zulu (GMT). You should never store or compute time values with reference to time zones.
Your examples have times that seem to come from different messages. It would help to explain your problem by using the value from the same message. |
We are just mapping one message from MRM-CWF into MRM-XML format by using the SELECT function. We are not doing any computation with these values.
I was wondering why dateTime gets a timezone +02:00 whereas time gets a timezone of +01:00 within the same message.
Thanks for the link but I think that does not help as the problem seems to occur when using SELECT statement to map the message tree into a different format. _________________ IBM Certified Solution Designer - WebSphere MQ V6.0
IBM Certified Solution Developer - WebSphere Message Broker V6.0
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
Back to top |
|
 |
lancelotlinc |
Posted: Wed Oct 19, 2011 7:30 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
There is more than one hour difference between the two times.
'13:54:28' - '09:11:57' = 4:43:31 difference ?
These two times have no relationship to each other, apparently. Or, spoken another way, what makes the 9 time different from the 13 time? _________________ http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
Back to top |
|
 |
j.f.sorge |
Posted: Wed Oct 19, 2011 7:37 am Post subject: |
|
|
Master
Joined: 27 Feb 2008 Posts: 218
|
lancelotlinc wrote: |
There is more than one hour difference between the two times.
'13:54:28' - '09:11:57' = 4:43:31 difference ?
These two times have no relationship to each other, apparently. |
Thanks! You have computed the difference correctly!
Both value, the time within the dateTime / TIMESTAMP and the second time value, does not have any relationship! They have the same relationship than a and b.
My question is still: why are there different timezones attached to these independent values?! Why does dateTime / TIMESTAMP get +02:00 whereas time / TIME gets +01:00?!?! _________________ IBM Certified Solution Designer - WebSphere MQ V6.0
IBM Certified Solution Developer - WebSphere Message Broker V6.0
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
Back to top |
|
 |
lancelotlinc |
Posted: Wed Oct 19, 2011 7:45 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
|
Back to top |
|
 |
j.f.sorge |
Posted: Wed Oct 19, 2011 8:01 am Post subject: |
|
|
Master
Joined: 27 Feb 2008 Posts: 218
|
lancelotlinc wrote: |
The source of the TZ Offset may be different between the functions. |
Which funtions do you mean? Broker-internal function for dateTime and time handling?
I've checked the environment variables
Code: |
$ echo $TZ
MET
$ locale
LANG=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
LC_NUMERIC=en_US.UTF-8
LC_TIME=en_US.UTF-8
LC_COLLATE=en_US.UTF-8
LC_MONETARY=en_US.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_ALL=en_US.UTF-8
$ echo $LANG
en_US.UTF-8
$ echo $LC_ALL
en_US.UTF-8 |
but I still do not really understand the different timezones within one message but for different data types as TZ=MET lets me think of timezone suffix of +01:00 for each data type. _________________ IBM Certified Solution Designer - WebSphere MQ V6.0
IBM Certified Solution Developer - WebSphere Message Broker V6.0
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
Back to top |
|
 |
lancelotlinc |
Posted: Wed Oct 19, 2011 8:22 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
In some cases, Broker refers to the underlying OS details to determine TZ Offset, in other cases not. There is an APAR for some timezone offsets not being represented correctly (Australia). It is due out in WMB version 7.0.0.4.
Nonetheless, the whole issue is moot. You should never store time values in any tz other than GMT/Zulu. Storage includes embedded in a message or in a database.
Timezones are for humans who sleep. Computers do not sleep and therefore need no reference to timezones.
The only instance where your code needs to refer to a tz offset is when your code is rendering a display to a human. In all other cases, all references to all times should be synchronized to GMT. _________________ http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
Back to top |
|
 |
j.f.sorge |
Posted: Wed Oct 19, 2011 8:54 am Post subject: |
|
|
Master
Joined: 27 Feb 2008 Posts: 218
|
lancelotlinc wrote: |
In some cases, Broker refers to the underlying OS details to determine TZ Offset, in other cases not. There is an APAR for some timezone offsets not being represented correctly (Australia). It is due out in WMB version 7.0.0.4. |
As stated above we're still using 6.1 so an APAR for 7.0 won't help here.
lancelotlinc wrote: |
Nonetheless, the whole issue is moot. You should never store time values in any tz other than GMT/Zulu. Storage includes embedded in a message or in a database.
Timezones are for humans who sleep. Computers do not sleep and therefore need no reference to timezones.
The only instance where your code needs to refer to a tz offset is when your code is rendering a display to a human. In all other cases, all references to all times should be synchronized to GMT. |
I'll think about transforming the data we get (which will be in local timezone without any timezone information) into GMT to make it computer-readable. Another chance will be to use a different format HH:mm:ss at output which cuts the timezone information completely. _________________ IBM Certified Solution Designer - WebSphere MQ V6.0
IBM Certified Solution Developer - WebSphere Message Broker V6.0
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
Back to top |
|
 |
lancelotlinc |
Posted: Wed Oct 19, 2011 8:57 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
|
Back to top |
|
 |
j.f.sorge |
Posted: Wed Oct 19, 2011 9:04 am Post subject: |
|
|
Master
Joined: 27 Feb 2008 Posts: 218
|
lancelotlinc wrote: |
Good luck! Wish you the best. Please repost if you run into a show-stopper. |
Thanks! I will update this thread after I have completed this task. _________________ IBM Certified Solution Designer - WebSphere MQ V6.0
IBM Certified Solution Developer - WebSphere Message Broker V6.0
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed Oct 19, 2011 9:45 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
j.f.sorge wrote: |
lancelotlinc wrote: |
Good luck! Wish you the best. Please repost if you run into a show-stopper. |
Thanks! I will update this thread after I have completed this task. |
I seem to remember from V6.0 that where WMB is good transforming date/time /timestamp information from local to GMT as it occurs it does not handle adequately historical info as it uses the current offset and not the historical offset.
This would be why using a java function for this might be helpful.  _________________ MQ & Broker admin |
|
Back to top |
|
 |
rekarm01 |
Posted: Fri Oct 21, 2011 5:29 pm Post subject: Re: timezone mismatch in MRM on dateTime & time |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 1415
|
j.f.sorge wrote: |
lancelotlinc wrote: |
'13:54:28' - '09:11:57' = 4:43:31 difference ? |
Thanks! You have computed the difference correctly! |
Sadly, ... no.
j.f.sorge wrote: |
My question is still: why are there different timezones attached to these independent values?! Why does dateTime / TIMESTAMP get +02:00 whereas time / TIME gets +01:00?!?! |
There is no date specified for ESQL TIME values. Perhaps it's assuming the epoch date (1970-01-01) instead, when the local timezone offset was +01:00. |
|
Back to top |
|
 |
|