| Author |
Message
|
| wibble7 |
 Posted: Wed Aug 08, 2012 6:39 am Post subject: Broker v7 TIMEZONE issue |
 |
|
Novice
Joined: 30 Apr 2012
Posts: 18
|
Hi,
I have some esql code which is creating a string output in a response message, as part of that string it includes a CAST(CURRENT_TIMESTAMP AS CHAR). However this currently returns a time which is equivalent to the GMT/UTC time, i.e. an hour behind. I've executed mqsiservice -t and get:-
BIPmsgs en_GB
Console CCSID=819, ICU CCSID=819
Default codepage=ISO-8859-1, in ascii=ISO-8859-1
JAVA console codepage name=ISO-8859-1
ICU Version: 3.8.1
ICU TZ Data Version: 2011g
Current Local time: 2012-08-08 14:34:49.716696
Current UTC time: 2012-08-08 14:34:49.716741
Env TZ: Europe/London
ICU TimeZone ID: Europe/London
Standard offset from GMT: 0
Supports DST? true
Locating DST boundaries
GMT Local DST Mins
2012-01-01 13:00:00 2012-01-01 13:00:00 0
2012-03-24 13:00:00 2012-03-24 13:00:00 0
2012-03-25 13:00:00 2012-03-25 14:00:00 60
2012-10-27 13:00:00 2012-10-27 14:00:00 60
2012-10-28 13:00:00 2012-10-28 13:00:00 0
Day Names: Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday,
Month Names: January, February, March, April, May, June, July, August, September , October, November, December,
First day of week: 2
Days in first week of year: 1
AM: AM PM: PM
Can anyone suggest why its incorrect especially when the boundary dates are correct?
Are those really the times that DST takes place, shouldn't it be 01:00:00 and 02:00:00? |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Wed Aug 08, 2012 6:53 am Post subject: Re: Broker v7 TIMEZONE issue |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| wibble7 wrote: |
| CAST(CURRENT_TIMESTAMP AS CHAR). However this currently returns a time which is equivalent to the GMT/UTC time. |
This is the correct behavior and the product is working as designed.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| wibble7 |
| Posted: Wed Aug 08, 2012 7:09 am Post subject: |
|
|
Novice
Joined: 30 Apr 2012
Posts: 18
|
I don't believe that is the correct behaviour, the info centre has this description for CURRENT_TIMESTAMP
CURRENT_TIMESTAMP returns a TIMESTAMP value representing the current date and local time. As with all SQL functions that take no parameters, no parentheses are required or accepted. All calls to CURRENT_TIMESTAMP within the processing of one node are guaranteed to return the same value.
the local time for the timezone Europe/London which was returned in mqsiservice -t should be GMT + 1:00 dues to the current DST, so CURRENT_TIMESTAMP should return a time thats an hour different to CURRENT_GMTTIMESTAMP which it doesn't. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Aug 08, 2012 7:26 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Aug 08, 2012 7:31 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| wibble7 wrote: |
| the local time for the timezone Europe/London which was returned in mqsiservice -t should be GMT + 1:00 dues to the current DST, so CURRENT_TIMESTAMP should return a time thats an hour different to CURRENT_GMTTIMESTAMP which it doesn't. |
| wibble7 wrote: |
Current Local time: 2012-08-08 14:34:49.716696
Current UTC time: 2012-08-08 14:34:49.716741
Env TZ: Europe/London
ICU TimeZone ID: Europe/London
Standard offset from GMT: 0
|
According to this the local DST time is the same as GMT, hence CURRENT_TIMESTAMP is returning the same value as CURRENT_GMTTIMESTAMP.
I would suspect that the server on which WMB is running has the DST set by the sys admins advancing or retarding the system clock once a year, rather than using the OS facilities. You'd be surprised how often I've seen that done, and how few good reasons I've heard for it.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| wibble7 |
| Posted: Thu Aug 09, 2012 12:32 am Post subject: |
|
|
Novice
Joined: 30 Apr 2012
Posts: 18
|
we have mq and itcam on the same server, if i run date under those id's and my own the time is returned correctly, if the server time had been advanced wouldn't that mean the GMT time would be incorrect but would match the local time.
its from the mqsiservice -t response that i'm interetsed to know why the local time and utc time's are the same given that under the dst boundaries it knows how many minutes it needs to add or subtract and on what days to account for BST.
any suggestions anyone? |
|
| Back to top |
|
|
| wibble7 |
| Posted: Thu Aug 09, 2012 1:01 am Post subject: |
|
|
Novice
Joined: 30 Apr 2012
Posts: 18
|
| we are running message broker 7 with fixpack 3 |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Aug 09, 2012 4:57 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| wibble7 wrote: |
| we are running message broker 7 with fixpack 3 |
Message broker versions have 4 digits. The runtime version can and usually is different than the toolkit.
What is your runtime version? And what is the "effective level"? Use mqsireportbroker to find out.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| wibble7 |
| Posted: Thu Aug 09, 2012 5:21 am Post subject: |
|
|
Novice
Joined: 30 Apr 2012
Posts: 18
|
MQSI 7.0.0.3
/opt/IBM/mqsi/7.0
wmb01@ebmbdv11:wmb01> mqsireportbroker DVESB01
BIP8927I: Broker Name 'DVESB01'
Install path = '/opt/IBM/mqsi/7.0'
Work path = '/var/mqsi'
Broker UUID = '737843f4-f031-11e0-996c-000000000000'
Process id = '4325422'
Queue Manager = 'DVESB01'
User lil path = ''
User exit path = ''
Active user exits = ''
LDAP principal = ''
LDAP credentials = ''
ICU converter path = ''
Trusted (fastpath) Queue Manager application = 'false'
Configuration change timeout = '300' seconds
Internal configuration timeout = '60' seconds
Statistics major interval = '60' minutes
Operation mode = 'enterprise'
Fixpack capability level = '' (effective level '7.0.0.1')
Broker registry format = 'v7.0'
Administration security = 'active'
Multi-instance Broker = 'false'
Shared Work Path = 'none'
Start as WebSphere MQ Service = 'undefined'
HTTP listener port = '7180'
BIP8071I: Successful command completion. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Aug 09, 2012 5:23 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| wibble7 wrote: |
MQSI 7.0.0.3
Fixpack capability level = '' (effective level '7.0.0.1')
|
This says you are not on FixPack 3. You should be at least to 7.0.0.4 by now.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Aug 09, 2012 5:24 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
so you could mqsichangebroker to set the effective level to 7.0.0.3 and that might provide access to a bug fix.
Also, it's still possible that the change to DST was made in the wrong manner.
Did you confirm that the shell that issues mqsistart shows the correct time *before* you issue mqsistart?
I.e. restart the broker and make sure that the time and timezone and dst settings in the shell that you're going to run mqsistart from is *correct* before you run mqsistart. |
|
| Back to top |
|
|
| wibble7 |
| Posted: Thu Aug 09, 2012 5:53 am Post subject: |
|
|
Novice
Joined: 30 Apr 2012
Posts: 18
|
| Does the Fixpack Capability level refer to the functional or maintenance element of a fix pack, I was under the imprerssion that when you install a fixpack the maintenance (bug fixes etc) was automatically applied and that you only run mqsichangebroker to enable the new fuctionality? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Aug 09, 2012 5:55 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| wibble7 wrote: |
| Does the Fixpack Capability level refer to the functional or maintenance element of a fix pack, I was under the imprerssion that when you install a fixpack the maintenance (bug fixes etc) was automatically applied and that you only run mqsichangebroker to enable the new fuctionality? |
It depends on the fix in question, alas. Clearly it won't apply fixes that are used by features that aren't enabled. And there are changes to the way things work in new levels, as well.
Regardless, if you open a PMR you're very likely to get told to enable 7.0.0.3 anyway. So save a step, and potentially skip opening a PMR in the first place if it fixes the problem. |
|
| Back to top |
|
|
| wibble7 |
| Posted: Fri Aug 10, 2012 3:06 am Post subject: |
|
|
Novice
Joined: 30 Apr 2012
Posts: 18
|
| Enabled the latest fixpacks functionality but that hasn't made any difference. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Aug 10, 2012 5:15 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Was does the OS say under the broker's service ID? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
