Timezones
Timezones are a problem for many Web applications. Browsers do not provide information about timezone to the server, so applications have to provide information that makes clear how dates and times are being presented and input interpreted
Failing to do this can result in odd or even humorous results, such as events "coming from the future." In addition, to make matters more complex, back end resources (adapters, applications, Web services, and especially databases) may be in another timezone or may handle timezones poorly themselves.
In particular, many databases do not store timezone information in their time-based data types (such as timestamp). The database relies on the user to modify times appropriately—and most drivers, such as JDBC, do not do this for you, even when their API suggests that they do.
The key thing to remember about dates and times in Java is that there is a difference between the java.util.Date object and what you see on the screen (which I call a "calendric" date).
Java Date objects are basically a wrapper around a long&mash;the number of milliseconds since the Java Epoch date (which happens to be 1 January 1980 at midnight). This value is always UTC and thus is timezone independent.
The display or calendric time is different. In fact, there are times when a Java Date object doesn't describe your data best. For example: if you solicit a person's birthdate, then converting the date to UTC can have odd timezone effects.
To see this in action, try the Global Meeting Planner below...
