Changing the timezone of a date, not only display

[Rohits Shah]

Hi,

I am getting the date from the database as type java.util.Date, therefore it takes the timezone of my machine
i.e. EST, now if I want to change its timezone to GMT, not of the display but the date itself, does anybody have a solution for this?

Thanks in advance,
rshah82

[Nitesh Kant]

In java.util.Calendar you can set time zones.
So, you can basically create a Calendar object with the same time zone as Date. Use setTime(Date date) method to set the date object that you have and then change the time zone using setTimeZone().

[Rohits Shah]

Actually the solution does not seem to work the way I need it, what I actually need is as follows:

1. I have an DB where I store information in timestamp format without timezone.
2. I get that timetsamp from db in the form of java.util.Date from hibernate and as discussed java.util.Date does not store the timezone
3. But the java.util.Date appends the timezone of the application server to the information its carries, so it assumes that whatever timezone it gets from the 'Application Server' timezone and appends it to the info. You can see that by printing a java.util.Date variable, it displays the timezone.
4. So suppose if now I am getting Apr 4 2008 7:00 from the DB into a java.util.Date variable, the java.util.Date by itself will append EST as my application server is in EST but I want to append GMT to it somehow. Like I want Apr 4 2008 7:00 GMT and not Apr 4 2008 7:00 EST.
5. This is just beacuse I would then convert into whatever timezone I need and display, like for the above I would display Apr 4 2008 3:00 EST

I guess this small example should be more useful.

Thanks again,
Rohits

[Nitesh Kant]

rohits: I have an DB where I store information in timestamp format without timezone.

Oh I dont think this is correct. I assume you always store and read it using the same timezone. People generally store it in GMT.

rohits: So suppose if now I am getting Apr 4 2008 7:00 from the DB into a java.util.Date variable, the java.util.Date by itself will append EST as my application server is in EST but I want to append GMT to it somehow. Like I want Apr 4 2008 7:00 GMT and not Apr 4 2008 7:00 EST.

I think your problem is that hibernate thinks that the timezone is EST whereas you have stored the time as GMT.
A casual search gave me this article. May be it wil help.
I have no idea about hibernate. May be you will get better results asking this question on the hibernate forum

[Kiran Dalvi]

I hope you solved your problem. I had exact same requirement and here is how I got it -

This does convert the time/date to UTC as well as displays as "UTC" when printed as String.

public class UTCTime {

public static Date getCurrentUTCTime() {
Calendar cal = Calendar.getInstance(Locale.getDefault());
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));

return cal.getTime();
}
}

[Darryl Burke]

java.util.Date does not have a timezone. The class represents an instant in time, internally held as a long which is the number of milliseconds since the Epoch.

[Kiran Dalvi]

You are absolutely correct. java.util.Date does not have a Time Zone associated with it.
The issue here was when printing toString() on a Date object, it does show a TimeZone (Of an AppServer/Local Machine) and we needed to change that displayed value as well.

public class UTCTimeTester {
public static void main(String[] args) {
System.out.println("Current UTC Time = " + UTCTime.getCurrentUTCTime());
}
}

Output -
Current UTC Time = Mon May 21 08:06:55 UTC 2012

[Darryl Burke]

Kiran Dalvi wrote:You are absolutely correct. java.util.Date does not have a Time Zone associated with it.
The issue here was when printing toString() on a Date object, it does show a TimeZone (Of an AppServer/Local Machine) and we needed to change that displayed value as well.

That's what a DateFormat is for.

[Jesper de Jong]

The only reason why you now see the date printed in UTC is because you are setting the default timezone of the JVM to UTC with this line:

TimeZone.setDefault(TimeZone.getTimeZone("UTC"));

Note that now all Date objects will be printed with UTC, not just the Date object that is returned by the method.

That's most likely not what you want!

[Kiran Dalvi]

Ok.
So, how do we solve this problem? I want to get the current date (java.util.Date) from this class and should be UTC. DateFormat gives me only display. I want the Date object to contain UTC time.
I appreciate your help.

[Jeff Verdegan]

Kiran Dalvi wrote: I want the Date object to contain UTC time.

Impossible, since Date objects do not have a TZ. I'm not sure why you're asking, since you already stated that you understand this fact.

A Date object just represents an instant in time. "Now" is "now", no matter what TZ you are in (if we ignore special relativity, which I think it's safe to do here ).

[Kiran Dalvi]

Thanks. I decided to use Calendar for display purposes and Date only for manipulation/DB updates. Here is what I came up with -

public class UTCTimeTester {
	
	public static void main(String[] args) {
		
		UTCTime.displayUTCTime();
		Date date = UTCTime.getDate();
		
	}

}

public class UTCTime {
	
	public static final int UTC_HOUR_DIFFERENCE = -5;
	public static final int UTC_MINUTE_DIFFERENCE = -30;
	
	public static void displayUTCTime()	{
		
		GregorianCalendar cal = new GregorianCalendar(TimeZone.getTimeZone("UTC"), Locale.getDefault());
		cal.setTimeZone(TimeZone.getTimeZone("UTC"));
		
		int year =   cal.get(GregorianCalendar.YEAR);
	    int month =  cal.get(GregorianCalendar.MONTH);      
	    int day =    cal.get(GregorianCalendar.DAY_OF_MONTH);
	    int hour =   cal.get(GregorianCalendar.HOUR_OF_DAY);
	    int minute = cal.get(GregorianCalendar.MINUTE);
	    int second = cal.get(GregorianCalendar.SECOND);
	   
	    System.out.printf("UTC Date Time = %4d/%02d/%02d %02d:%02d:%02d\n",  year, month+1, day, hour, minute, second);	    
	}
	
	public static Date getDate () {
		
		GregorianCalendar cal = new GregorianCalendar(TimeZone.getTimeZone("UTC"), Locale.getDefault());
		cal.setTimeZone(TimeZone.getTimeZone("UTC"));
		decrementHours(cal);
		decrementMinutes(cal);
		return cal.getTime();
	}	

    private static GregorianCalendar decrementHours(GregorianCalendar cal) {
       
        cal.add(GregorianCalendar.HOUR, UTC_HOUR_DIFFERENCE);        
        return cal;
    }
    
    private static GregorianCalendar decrementMinutes(GregorianCalendar cal) {
        
        cal.add(GregorianCalendar.MINUTE, UTC_MINUTE_DIFFERENCE);
        return cal;
    }
}

[Jesper de Jong]

You're making it much more complicated than necessary.

Why don't you just use a DateFormat to display the date in whatever timezone you want? Here's how you could write your displayUTCTime() method:

public static void displayUTCTime()	{
    DateFormat df = new SimpleDateFormat("yyyy/MM/dd HH:mm:ss");
    df.setTimeZone(TimeZone.getTimeZone("UTC"));

    System.out.println(df.format(new Date()));
}

What your getDate() method does is a little bit strange. A Date object represents an absolute moment in time, independent of any time zone. Your getDate() method just takes the current time ("now") and subtracts 5 hours and 30 minutes from it. What you're getting is not the time in UTC, but a Date object that represents "now" minus 5 hours and 30 minutes, regardless of the time zone.

Your decrementHours() and decrementMinutes() methods have confusing names, because what they do is add an offset (which happens to be negative).

[Kiran Dalvi]

Thanks for the reply. I am trying to fulfill 2 requirements -
1. Whenever I display date+time on my site, it should be UTC.
2. All calculations on the Date+Time should happen on UTC alongwith DB persistance.
3. My AppServer runs in India (UTC+5.5)

With your solution, I can achieve (1) but can't possibly achieve(2).

With -
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
I can achieve it. Only issue would be in case I need to use my local time somewhere in future, I would be handicapped.
So I am trying to go around it.

[Darryl Burke]

Kiran Dalvi wrote:Thanks for the reply. I am trying to fulfill 2 requirements -
1. Whenever I display date+time on my site, it should be UTC.
2. All calculations on the Date+Time should happen on UTC alongwith DB persistance.
3. My AppServer runs in India (UTC+5.5)

With your solution, I can achieve (1) but can't possibly achieve(2).

The long value internally stored by a Date instance doesn't get changed by setting the default TimeZone. It doesn't depend on the TimeZone at all, only on the number od milliseconds since the Epoch.

The Epoch was the same instant of time everywhere.

[Jeff Verdegan]

Darryl Burke wrote:

Kiran Dalvi wrote:Thanks for the reply. I am trying to fulfill 2 requirements -
1. Whenever I display date+time on my site, it should be UTC.
2. All calculations on the Date+Time should happen on UTC alongwith DB persistance.
3. My AppServer runs in India (UTC+5.5)

With your solution, I can achieve (1) but can't possibly achieve(2).

The long value internally stored by a Date instance doesn't get changed by setting the default TimeZone. It doesn't depend on the TimeZone at all, only on the number od milliseconds since the Epoch.

The Epoch was the same instant of time everywhere.

So, IF your database handles times correctly, and IF you have the correct column definition, then all you need to do is call PreparedStatement.setTimestamp(int parameterIndex, Timestamp x) to store the date and time, and the corresponding ResultSet.getTimestamp() to retrieve it. It won't matter what TZ your server or your client is in--you'll have the instant in time, independent of any TZ, and you can format it for whatever TZ you want when it comes time to display it.

Now, depending on how your database handles times, you may instead need setTimestamp(int parameterIndex, Timestamp x, Calendar cal) and the corresponding getTimestamp(String columnLabel, Calendar cal). If I recall correctly, I've seen some inconsistencies and non-intuitive behaviors across different DBs' handling of times, but one of these method pairs should be all you need. You'll just have to do some testing with different combinations to make sure you get what you expect.

[Kiran Dalvi]

Thanks. Much more clear now.
Looks like changing JVM TimeZone suits the best to what I am looking for.

Below does give me the Date which I am looking for.

	public static Date getUTCTime() {
		TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
		return new Date();
	}

System.out.println(UTCTime.getUTCTime());
Mon May 21 13:30:00 UTC 2012
[Current time where my JVM is running is 19:00:00]

[Jeff Verdegan]

Kiran Dalvi wrote:Thanks. Much more clear now.
Looks like changing JVM TimeZone suits the best to what I am looking for.

That doesn't sound right, and it's certainly not the message that anybody here was trying to convey.

[Kiran Dalvi]

Thanks Jeff.
I will try the handle insert/update on DB side using Timestamp as you suggested [as opposed to playing with the original Date object]. For displaying, I will use DateFormat.

[Martin Vashko]

Jeff Verdegan wrote:
Now, depending on how your database handles times, you may instead need setTimestamp(int parameterIndex, Timestamp x, Calendar cal) and the corresponding getTimestamp(String columnLabel, Calendar cal). If I recall correctly, I've seen some inconsistencies and non-intuitive behaviors across different DBs' handling of times, but one of these method pairs should be all you need. You'll just have to do some testing with different combinations to make sure you get what you expect.

I'm using this method to set data types which do not hold timezone information; the passed Timestamp time instant is stored in (ie. converted to) the timezone of given Calendar instance.

Any problems probably have to do not with databases, but with JDBC drivers. I've discovered this bug in jTDS driver recently. (I've dug quite deep on this issue and some notes in the source code seem to indicate that the developers of the driver were not exactly sure what this method is supposed to do; though the bug does not stem from such misunderstanding - the basics are right, just the Daylight Saving Time transition is not handled properly.)

I sincerely advise to concentrate the testing on Daylight Saving Time transitions of all participating time zones...