[paibanez]

Hi Isomorphic,

You are correct!! Those milliseconds do not have any effect on the SQL statement.

So lets say, the DSRequest sent contains the same date object created initially. Great!!

But what I am trying to demonstrate you is that the SQL query generated applies a Timezone to the date when it creates the Datetime string parameter on the query:

The GMT conversion of the original Date:

Date GMT: 27 Jun 2013 13:19:32 GMT

and the SQL query statement:

=== 2013-06-27 15:19:33,049 [l0-6] INFO  SQLDriver - [builtinApplication.testCase_add] Executing SQL update on 'Mysql': INSERT INTO testcase (date) VALUES ('2013-06-27 15:19:32')

As you see, it applies a +02:00 timezone to date when it creates the SQL query statement.

Would you please tell me if this problem is on a misconfiguration of my SQL Database Server or the SQL driver in order to focus on the DB Server and assume SmartGWT is correct?

Thank you very much and I think I am near the end ;)

Best regards,

Pablo

[paibanez]

Hi Isomorphic,

Finally, after working hard all day I found a SOLUTION.

The problem seems to be the conversion of the original date object to the SQL query by the MySQL connector driver. This conversion is always using the local timezone of the JVM where the war is deployed.

So the SOLUTION I have used is to set the timezone of the Web Server JVM to GMT via the java parameter -Duser.timezone=GMT.

Is this the only solution?

I wish this solution could help anyone with the same problem in order not to spend as much time and efforts as I have spent.

Thank you very much for your responses.

Best regards,

Pablo

[Isomorphic]

Using the server timezone is what JDBC drivers do by default (and also Hibernate, since it just lets the JDBC driver handle this).

We do have a special flag settable in server.properties to force UTC even when the server timezone is not UTC:

sql.MySQL.useUTCDateTimes: true