ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » timezone mismatch in MRM on dateTime & time

Post new topic  Reply to topic
 timezone mismatch in MRM on dateTime & time « View previous topic :: View next topic » 
Author Message
j.f.sorge
PostPosted: Wed Oct 19, 2011 5:15 am    Post subject: timezone mismatch in MRM on dateTime & time Reply with quote

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
View user's profile Send private message
lancelotlinc
PostPosted: Wed Oct 19, 2011 5:32 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
mqjeff
PostPosted: Wed Oct 19, 2011 5:37 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

http://publib.boulder.ibm.com/infocenter/wmbhelp/v7r0m0/index.jsp?topic=%2Fcom.ibm.etools.mft.doc%2Fac05940_.htm
Back to top
View user's profile Send private message
j.f.sorge
PostPosted: Wed Oct 19, 2011 7:27 am    Post subject: Reply with quote

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.

mqjeff wrote:
http://publib.boulder.ibm.com/infocenter/wmbhelp/v7r0m0/index.jsp?topic=%2Fcom.ibm.etools.mft.doc%2Fac05940_.htm

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
View user's profile Send private message
lancelotlinc
PostPosted: Wed Oct 19, 2011 7:30 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
j.f.sorge
PostPosted: Wed Oct 19, 2011 7:37 am    Post subject: Reply with quote

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
View user's profile Send private message
lancelotlinc
PostPosted: Wed Oct 19, 2011 7:45 am    Post subject: Reply with quote

Jedi Knight

Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA

The source of the TZ Offset may be different between the functions.

http://publib.boulder.ibm.com/infocenter/wmbhelp/v7r0m0/index.jsp?topic=%2Fcom.ibm.etools.mft.doc%2Fae19494_.htm

Also, there may be some relationship between the source code page and the tz offset chosen.

http://www-01.ibm.com/support/docview.wss?uid=swg1IC73669

One may be referring to a locale that is calculating savings time as +0 where the other function may be referring to a locale which is calculating savings time as +1.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER
Back to top
View user's profile Send private message Send e-mail
j.f.sorge
PostPosted: Wed Oct 19, 2011 8:01 am    Post subject: Reply with quote

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?

lancelotlinc wrote:

http://publib.boulder.ibm.com/infocenter/wmbhelp/v7r0m0/index.jsp?topic=%2Fcom.ibm.etools.mft.doc%2Fae19494_.htm

Also, there may be some relationship between the source code page and the tz offset chosen.

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
View user's profile Send private message
lancelotlinc
PostPosted: Wed Oct 19, 2011 8:22 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
j.f.sorge
PostPosted: Wed Oct 19, 2011 8:54 am    Post subject: Reply with quote

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
View user's profile Send private message
lancelotlinc
PostPosted: Wed Oct 19, 2011 8:57 am    Post subject: Reply with quote

Jedi Knight

Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA

Good luck! Wish you the best. Please repost if you run into a show-stopper.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER
Back to top
View user's profile Send private message Send e-mail
j.f.sorge
PostPosted: Wed Oct 19, 2011 9:04 am    Post subject: Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Wed Oct 19, 2011 9:45 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
rekarm01
PostPosted: Fri Oct 21, 2011 5:29 pm    Post subject: Re: timezone mismatch in MRM on dateTime & time Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » timezone mismatch in MRM on dateTime & time
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.