|
(0067501)
|
|
sjkumar
|
2014-05-28 00:18
(edited on: 2014-05-28 00:24) |
|
Issue with different Time Zones in SPM | Reason for ?Tx is not active? error
1) While displaying a date type column in openbravo/SPM UI at IST timing zone, It is advancing the time stamp by 12 and half hours.
For example in database : one of a row in Usage table, has a Usage Starting Date as 05-27-2014 10:11:12.
but when I see the same date in SPM UI from IST zone place, It is coming as 05-27-2014 22:41:12 which is 12 and half hours ahead from database showed time stamp value
and when we see the same data from Mexico time zone, It is coming as 05-27-2014 12:11:12 which is two hours ahead from the database showed time stamp.
Because it stored as 05-01-2014 00:01:00 and validations have been passed. The below is the screenshot of it.
See detail attached - Tx Error-TimeZone Bug 18837473 .doc
|
|
|
|
Hi Sanjay,
The root cause under the Tx not active is when an EntityPersistenceEventObserver raises an exception in the middle of the computation (not directly related to the timezone issue but with any exception).
When an EntityPersistenceEventObserver raises an exception, it automatically deactivate the transaction (Tx), so the computation can't catch the exception and this ugly message about Tx is not active is shown.
In this kind of scenarios, the system should be able to catch the exception thrown by the EntityPersistenceEventObserver and log it to the user. We are working on it and we will fix it very soon.
On the other hand, the behaviour you're reporting about date and timezone is the expected one. Let me explain how it works:
Openbravo stores the dates (day, month, year, hour, minutes, seconds, milliseconds) without timezone information. So if you directly query the database, you will see a date without the timezone information.
Instead of storing the timezone information, Openbravo stores all the dates transformed to the server's timezone (Oracle and Tomcat timezone, which must be the same in both); in your case it is probably PST. That means that when you query the database, the dates you see are referenced to PST timezone in your case. Example if you see 12:00 in the database it means 12:00 in PST.
When the UI loads a date from the backend, the system automatically transforms it to the client's (web browser) timezone. It means that, if the server and the browser are in different timezones, you will see that the date displayed into the UI is different from the date you can see if you directly query the database. Example if you see 12:00 in the database, which means 12:00 in PST, it may be displayed (for example) at 21:00 in CEST timezone.
As a summary:
* Dates directly read in database are referenced to the server's timezone
* Dates loaded into the UI are automatically transformed by Openbravo from the server's timezone to the client's timezone.
* Obviously, if different clients in different timezone see the same date record loaded from the database, they will see it as different dates (with the correspondent offset between the client and server timezone). However, the absolute date (referenced to the common server's timezone) will be the same, and it's the one stored into the database.
Important: If you manually load dates into the database (through CSV, using SQL INSERT/UPDATE, or any other way outside of the UI), you must do it always in the server's timezone, to ensure all the dates reference to the same timezone.
Right now you're not taking this into account, and it's the reason why you get this problem each time the system updates a subscribed service line (computation process, manual update by the user, etc.). There is a validation run into an EntityPersistenceEventObserver that verifies the subscribed service lines fit into the subscription start date - end date range. |
|
Tx_error.log (45,414) 2014-04-25 06:26
openbravo.7z (143,288) 2014-05-08 06:34
Tx Error-TimeZone Bug 18837473 .doc (427,520) 2014-05-28 00:24