| Author |
Message
|
| Vitor |
 Posted: Thu Jun 05, 2014 5:47 am Post subject: |
 |
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| abcnil wrote: |
| My Broker is running in UTC+3 |
No it isn't - the broker is using the OS to obtain the time. So are you sure about it? I'm not doubting that when you ask it the time it gives you the right time, but is that the system clock directly, the system clock with a region setting, the system clock with a timezone setting or what?
| abcnil wrote: |
Output is coming as : Environment var from Debug:
ExecutionTs:CHARACTER:2014-03-15T16:13:27.1298+01:00 |
This indicates broker thinks you're only 1 hour ahead of GMT (sorry, UTC  ) not 3. The $64,000 question (or the equivalent Euro value) is where in the OS is it obtaining that value from?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
 |
| abcnil |
| Posted: Thu Jun 05, 2014 6:08 am Post subject: |
|
|
Apprentice
Joined: 29 Mar 2012
Posts: 36
|
Its +3
| Code: |
SET Environment.ExecutionTs = CAST(inputCardOrderRsHRsMsgRef.q1:ExecTimestamp AS CHARACTER FORMAT 'IU');
SET Environment.CurrentTs = CAST(CURRENT_TIMESTAMP AS CHARACTER FORMAT 'IU');
|
q1:ExecTimestamp is xsd:datetime type
and input value is
<q1:ExecTimestamp>2014-03-15T16:13:27.1298+01:00</q1:ExecTimestamp>
| Quote: |
ExecutionTs:CHARACTER:2014-03-15T16:13:27.1298+01:00
CurrentTs:CHARACTER:2014-06-05T17:05:20.671+03:00 |
 |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jun 05, 2014 6:21 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
What is? Your country's timezone or the OS clock? Just because you know your country uses +3 doesn't mean the OS does. I've worked on a lot of systems over the years where "daylight savings" is achieved by changing the OS clock +/- 1 hour, which really does a number on anything trying to use GMT.
| abcnil wrote: |
| |
I AM helping!
What I'm saying is that there's nothing wrong with your code.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| abcnil |
| Posted: Thu Jun 05, 2014 6:33 am Post subject: |
|
|
Apprentice
Joined: 29 Mar 2012
Posts: 36
|
Thanks Victor for helping
+3 is both machine (broker installed) and OS (toolkit installed).
My expectations are [as per documentation]:
This line should give
| Code: |
| SET Environment.ExecutionTs = CAST(inputCardOrderRsHRsMsgRef.q1:ExecTimestamp AS CHARACTER FORMAT 'IU'); |
Environment.ExecutionTs in Time in +3
as it gives for
| Code: |
| SET Environment.CurrentTs = CAST(CURRENT_TIMESTAMP AS CHARACTER FORMAT 'IU'); |
|
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jun 05, 2014 6:43 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| abcnil wrote: |
| My expectations are [as per documentation] |
And my point is that the reasons you're expectations are not being met is because the broker machine is not set up the way you think it is. As I indicated before, the fact it tells you the right time is not conclusive.
The time zone of your Toolkit is not releveant to this problem
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| abcnil |
| Posted: Thu Jun 05, 2014 7:54 am Post subject: |
|
|
Apprentice
Joined: 29 Mar 2012
Posts: 36
|
| Vitor wrote: |
And my point is that the reasons you're expectations are not being met is because the broker machine is not set up the way you think it is. As I indicated before, the fact it tells you the right time is not conclusive.
The time zone of your Toolkit is not releveant to this problem |
Hmm you might be right. BUT
Why its giving correct result for this statement...
| Code: |
| SET Environment.CurrentTs = CAST(CURRENT_TIMESTAMP AS CHARACTER FORMAT 'IU'); |
and not same for
| Code: |
| SET Environment.ExecutionTs = CAST(inputCardOrderRsHRsMsgRef.q1:ExecTimestamp AS CHARACTER FORMAT 'IU'); |
that i dont understand.
I believe for both statements it should refer to same TimeZone setting, isn't it 
or it takes CURRENT_TIMESTAMP from other than broker machine? |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jun 05, 2014 8:26 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| abcnil wrote: |
| I believe for both statements it should refer to same TimeZone setting, isn't it |
No. CURRENT_TIMESTAMP has a time zone derived from the local machine (and CURRENT_GMTTIMESTAMP has none). The data you're reading from the XML has a time zone associated with it which WMB interprets.
Bear in mind that if you're confident in your own mind that this is an inconsistant behaviour and/or WMB is not doing what the documentation says, it's PMR time. If you're sure that the code is right, and you're sure that the server settings are right, then you've found a bug. They do exist.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| abcnil |
| Posted: Thu Jun 05, 2014 9:30 am Post subject: |
|
|
Apprentice
Joined: 29 Mar 2012
Posts: 36
|
| Vitor wrote: |
No. CURRENT_TIMESTAMP has a time zone derived from the local machine (and CURRENT_GMTTIMESTAMP has none). The data you're reading from the XML has a time zone associated with it which WMB interprets. |
Ohh!!! Now i see the difference. Nice to learn this thanks victor
| Vitor wrote: |
Bear in mind that if you're confident in your own mind that this is an inconsistant behaviour and/or WMB is not doing what the documentation says, it's PMR time. If you're sure that the code is right, and you're sure that the server settings are right, then you've found a bug. They do exist. |
Hmm need to double check what my Remote broker settings does have. n then go for PMR |
|
| Back to top |
|
|
|
|
