tags:

views:

196

answers:

4

I have a db, that stores dates in OleDateTime format, in GMT timezone. I've implemented a class, extending Date in java to represent that in classic date format. But my class is locale-dependent (I'm in GMT+2). Therefore, it converts the date in the db as date - 2 hours. How do I make it convert the date correctly? I want my class to be locale-independent, always using GMT timezone. Actually, the question is:

class MyOleDateTime extends Date {

    static {
        Locale.setDefault(WhatGoesHere?)
    }

    // ... some constructors
    // ... some methods
}
A: 

Use a Calendar object:

Calendar cal = Calendar.getInstance(TimeZone.getTimeZone("GMT"),
                                    locale);
kgiannakakis
My class is used as Date in numerous places, I cannot change that.
folone
+1  A: 

Well, it's better to use the Calendar object like suggested in other answers. However, if you really want to set global timezone, you can use TimeZone.setDefault(TimeZone.getTimeZone("UTC")); early in your application code. There is also user.timezone Java system property.

Also (just fun to know), it appears that the only country actually living by GMT/UTC time (without daylight saving changes) is Liberia.

In fact, Date objects per se are always locale- and timezone-independent. Its getTime() method will always return the number of milliseconds passed since January 1, 1970 00:00:00 (not counting leap seconds) in UTC. But if you want to get something else than milliseconds, you have to use Calendar, which is timezone-dependent. But it is the right way to go. You don't use that deprecated methods in Date class, do you?

Alexander Temerev
Yeah, that's what I've been looking for, thanks a lot.
folone
*sigh* And there he goes, happily doing the wrong thing...
Michael Borgwardt
@Michael But I really do not have an access to the client code, that uses my class. And it *does* uses the deprecated Date api. What should I do then?
folone
@Alexander I actually don't. But I'm pretty sure, that my clients do. So how do I make things right, without breaking their code?
folone
@folone: If you can't get them to correct their already broken code, you'll have to live with an application that can break anytime some code changes the default timezone.
Michael Borgwardt
@Michael: That's definetely not cool. I'll try to convince guys from other teams to change their code accordingly. Thanks.
folone
+2  A: 

A Date *is* locale-independent, always using GMT timezone. It's just a wrapper around a millisecond timestamp in GMT (more correctly: UTC).

The only things in Date that are timezone dependant are the deprecated methods like getDay() - that's why they're deprecated. Those use the default time zone. The correct thing to do is to avoid using those deprecated methods - not to set the default timezone to UTC! That could cause problems elsewhere, and you can't prevent other parts of the code from setting the default timezone to something else.

Michael Borgwardt
A: 

As Michael Borgwardt has already said, the Java Date object does not know anything about timezones. It's just a wrapper for a number of milliseconds since 01-01-1970 00:00:00 UTC.

You start dealing with timezones only when you for example convert the Date object to a String using a DateFormat. You set the timezone on the DateFormat to specify in which timezone you want to see the Date.

DateFormat df = new SimpleDateFormat("dd-MM-yyyy HH:mm:ss Z");
df.setTimeZone(TimeZone.getTimeZone("UTC"));

String text = df.format(date);  // text will contain date represented in UTC
Jesper