0

I have a Client-Server based java application.The client is running in US/Pacific timezone and the server in UTC( I am saving the time in the database in UTC)

So for example, if I save the date as 09:00 Hrs Pacific time, it gets saved in the DB as 14:00 Hrs UTC.

When I read this time back from DB, daylight saving gets applied and it now gets converted to 08:00 hrs pacific time instead of 09:00 hrs.

So when converting from Pacific time to UTC, no daylight saving is considered, but when converting back from UTC to Pacific, it is applied which is not consistent.

In the DB, the column type is TIME and in java I am reading it into a date object.

How do I handle this ?

Dunxton
  • 408
  • 1
  • 8
  • 21
  • But this sounds like the right thing already? At that moment, it really is 8 instead of 9? – Amir Raminfar May 25 '12 at 15:59
  • How can it be correct when at one instance I am saving the time as 9 and at the very next instance it is being converted to 8 – Dunxton May 25 '12 at 16:06
  • Is it over the same jdbc connection? Because the time is actually converted by JDBC. – Amir Raminfar May 25 '12 at 16:28
  • As I move the date object from server to client, the date is automatically convert to the local time zone, not by JDBC – Dunxton May 25 '12 at 17:30
  • No, the underlying JDBC is the one responsible for creating the Date object. Please read http://docs.oracle.com/javase/1.4.2/docs/api/java/sql/ResultSet.html#getDate%28int,%20java.util.Calendar%29 I have spent too much time on this. :) – Amir Raminfar May 25 '12 at 17:38
  • And according to mysql documentation, date object has no timezone info. However, you are using timestamp. I am pretty sure some where JDBC is the one who changes it to a Date. – Amir Raminfar May 25 '12 at 17:39

3 Answers3

0

Normally the DB server decides on the time, applies daylight savings or not, and the time zone, which UTC is a standard.

Suggestion:

  1. Maybe you want to set the time by the client side as a string field with another field for the time zone PST, EST, or whatever.
  2. Make a field just for the time zone, and calculate the time for display to the client side.
The Original Android
  • 6,147
  • 3
  • 26
  • 31
0

I think the best thing you can do is make sure as much of your time handling as possible is done free from time zones at all. For example, millis since the Unix Epoch. Then you only apply time zone data just before it is displayed to the user.

So, in this case, do not apply any local time assumptions when you report to the server and when you retrieve from the server. In this way, it is impossible to have mismatching time zone or DST treatment of the data.

James
  • 710
  • 6
  • 19
0

With all this aside, I suggest you use getLong manually and construct the Date object yourself.

Amir Raminfar
  • 33,777
  • 7
  • 93
  • 123