8

How can I change timezone of a java.sql.Timestamp object which was initially, instantiated to CST, to GMT?

abson
  • 9,148
  • 17
  • 50
  • 69

2 Answers2

17

java.sql.Timestamp objects don't have time zones - they are instants in time, like java.util.Date.

If you're thinking of them as being in a particular time zone, you may either be getting confused due to misleading output (e.g. something automatically converting that instant into a local time using a default time zone) or you may have created the data in an inappropriate way. The answer you need will depend on the details of your situation.

For example, if you just want to display a Timestamp value in a particular time zone, you can use SimpleDateFormat, set the time zone appropriately, and just format the Timestamp (as it extends Date). I don't believe that will allow you to display as much precision as the timestamp stores internally, but that may not be a problem for you.

If your data has been created incorrectly then there may or may not be a way to "correct" it - there may be some ambiguities due to daylight saving time changes, for example. However, the more we know about it the better we'll be able to help you.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • 3
    Thanks, Jon for the answer,but there is getTimezoneOffset(), a deprecated method in Timestamp which returns the offset from GMT in minutes, in my case it returns it to be 360 minutes. The desired result was to change this to 0, which will be the case with a GMT Timestamp. – abson Dec 21 '11 at 11:36
  • @abson: `getTimezoneOffset` is inherited from `Date` - it's *always* relative to the system default time zone. It's not part of the object at all, and shouldn't be used. – Jon Skeet Dec 21 '11 at 11:42
  • 3
    The timezone offset is definitely affecting the result. I have two timestamps in the DB. One before DST and one after DST. If I create a Calendar object using Timestamp's getTime() as its constructor parameter, it is fine for the before DST timestamp but not the after DST timestamp. It is incorrectly "correcting" it by one hour despite using Calendar.getInstance(TimeZone.getTimeZone("UTC")) to instantiate the Calendar object – the_new_mr Apr 04 '13 at 10:43
  • 2
    My problem appears to be an Oracle peculiarity. Seems you need to pass a calendar object with the required timezone when getting the timestamp (e.g. resultSet.getTimestamp("last_update_time_utc", calendar)) Here's a useful link explaining stuff: http://puretech.paawak.com/2010/11/02/how-to-handle-oracle-timestamp-with-timezone-from-java/ – the_new_mr Apr 04 '13 at 10:59
  • Archive.org backup for the previous comment's now-dead link: https://web.archive.org/web/20130924231308/http://puretech.paawak.com/2010/11/02/how-to-handle-oracle-timestamp-with-timezone-from-java/ – Matthew Read Jul 08 '20 at 03:25
9

Some Timestamp constructors do depend on the default timezone. One way to avoid this is to use the constructor that takes a long:

TimeZone.setDefault(TimeZone.getTimeZone("GMT"))
Timestamp.valueOf("2016-10-26 23:00:00").getTime()

res16: Long = 1477522800000 // This is what we want

TimeZone.setDefault(TimeZone.getTimeZone("GMT-1"))
Timestamp.valueOf("2016-10-26 23:00:00").getTime()

res14: Long = 1477526400000

new Timestamp(OffsetDateTime.of(2016,10,26,23,0,0,0,ZoneOffset.UTC).toInstant.toEpochMilli).getTime

res15: Long = 1477522800000 // We get the same result at in GMT
Mikael Valot
  • 444
  • 4
  • 6
  • The Javadoc on Timestamp doesn't mention it, but the underlying cause is it extends the Date object and uses it for construction. – Scott Markwell May 23 '18 at 19:53