What I propose is to keep all the time data in your database in UTC instead. This has a few advantages:

• The times in the database can be compared, visually and in SQL WHERE clauses.
• Using Java, you don't have to do any conversions when reading or writing to the database.
• When changing DST , values don't jump when transitioning to summer or winter time.

There is a small price to pay: manual interventions (mainly INSERT and UDPDATE) should take into account that UTC must be used, not local time.

Let's illustrate that with a concrete example:

A user John in New York enters a date/time for a planned teleconference with his colleague Mark in Brussels. He types 2009-07-06 09:30 , the application parses that to a Date - containing a long value of 1246887000000. This Date represents 14:30 UTC . It is inserted as such in the database.

On the other side of the Atlantic ocean, Mark checks the date of the planned meeting, the application reads the date from the database - it still represents 14:30 UTC and contains the same long value of 1246887000000. Mark's session contains a formatter that formats this date to 2009-07-06 15:30

The basic point is that each user's session contains a SimpleDateFormat , configured to the time zone of that particular user and parses or formats localized string representations of the actual (UTC) date in the database.

John would have probably preferred to enter the text 07/06/09 09:30 AM instead, and Mark would have preferred 60/07/09 15:30 , but that would complicate matters. So I chose to use an ISO style format.

In a real world example, users probably prefer to use a clickable calendar instead of a plain text entry.

java.util.Date is a wrapper for a long value that corresponds with the number of milliseconds since January 1, 1970, 00:00:00 UTC. You can obtain the current time using new Date() or System.out.currentTimeMillis() .

Now let us create a date instance and set it to a time, long, long ago. The 23rd day counting from the beginning of the year 1970. And that is in UTC!

We make one Date, and use SimpleDateFormat to render the date in the context of a particular time zone.

		
long time = 1000*60*60*24*23;
Date date = new Date(time);

TimeZone brusselsTZ = TimeZone.getTimeZone("Europe/Brussels");
TimeZone newYorkTZ = TimeZone.getTimeZone("America/New_York");

SimpleDateFormat formatterNY = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS");
SimpleDateFormat formatterBR = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS");

formatterNY.setTimeZone(newYorkTZ);
formatterBR.setTimeZone(brusselsTZ);

System.out.print("New York: ");
System.out.println(formatterNY.format(date));
//New York: 1970-01-23 19:00:00.000
System.out.print("Brussels: ");
System.out.println(formatterBR.format(date));
//Brussels: 1970-01-24 01:00:00.000
	
	

Want to create a Date from manual input? You can use the formatter to do that:

		
Date date2 = formatterBR.parse("2009-06-21 22:57:53.952");
System.out.println(date2);
//Sun Jun 21 22:57:53 CEST 2009
Date date3 = formatterBR.parse("2009-06-21 22:57");
//throws java.text.ParseException: Unparseable date: "2009-06-21 22:57"
	
	

A standard Java install contains all time zone information, it is maintained for all timezones and gets updates - as long as you apply them.

For server side applications with multiple concurrent users, you can offer the user choices for a preferred timezone. You can obtain the available namesas shown in the code fragment below. Do not set the default timezone in that case, it would affect all concurrent users if you relied upon it.

Be careful, timezones not only differ by the time offset relative to UTC, but also by the DST change rules.

	
String[] tzNames = TimeZone.getAvailableIDs();
...
String tzName = tzNames[n];
TimeZone timezone = TimeZone.getTimeZone(tzName);
...
	
	

Whatever you do, NEVER use all the deprecated methods on the Date class. If you need to calculate dates, use the Calendar class. if you need to parse dates, use SimpleDateFormat

These methods return values in the local time zone, i.e. the time zone obtained by TimeZone.getDefault() . They are somewhat awkward to use, e.g. months are zero based where 0 represents January etc.

Here we use a GregorianCalendar. We can set all the values at once with one of the 4 set(...) methods. We can also set the current time for the calendar with a Date or time in 'millis'.

		
Calendar calendar = new GregorianCalendar();
//calendar.setTime(date);
//calendar.setTimeInMillis(time);

calendar.set(2009, Calendar.AUGUST, 21);//Gotcha: months are 0-based, January == 0, December == 11
calendar.add(Calendar.DATE, 28);
System.out.println(formatterBR.format(calendar.getTime()));

//The time part was the time when new GregorianCalendar() was executed
//2009-09-18 13:12:53.341
	
	

Databases have some support for working with date/time values taking into account the existence of timezones. Most support is focused on interpreting and showing date/time in the timezone of the 'user' or connection. The fact that in a typical architecture, database connections are shared between application users, changing timezones per connection is not a feasible approach

There are no substantial differences. I still recommend to convert everything to UTC before updating or inserting values to the database.

As an illustration of the similarities and differences by vendor, here are some short descriptions of how PostgreSQL, Oracle and MySQL handle timezones:

2.4.1. PostgreSQL 8.1

2.4.2. Oracle 10g

	'2009-07-15 8:27:00 US/Pacific'
	'2009-12-15 15:33:00 -6:00'

2.4.3. MySQL 6.0

	SELECT CONVERT_TZ('2009-12-01 10:25','+00:00','-6:00')
	SELECT CONVERT_TZ('2009-12-01 10:25','UTC','Europe/Brussels')