Is Java's TimeZone thread-safe?

Question

I wanted my application to just have one TimeZone object which will be used by many SimpleDateFormat and Calendar objects from the other places concurrently. This is to avoid having to always do TimeZone.getTimeZone(ID).

I know SimpleDateFormat and Calendar classes are not thread safe, which is why I configure one thread to always create new instances of them. But what about TimeZone? It is not clear to me whether I can do the following safely:

final TimeZone tz = TimeZone.getTimeZone("GMT");
...
//Thread 1.
Thread t1 = new Thread(Runnable(){
    public void run()
    {
        Calendar cal = Calendar.getInstance(tz);
        ...
        SimpleDateFormat sdf = new SimpleDateFormat();
        sdf.setTimeZone(tz);
        ...
    }
});
t1.start();
...
//Thread 2.
Thread t2 = new Thread(Runnable(){
    public void run()
    {
        Calendar cal = Calendar.getInstance(tz);
        ...
        SimpleDateFormat sdf = new SimpleDateFormat();
        sdf.setTimeZone(tz);
        ...
    }
});
t2.start();
...

Thanks!

Answer 1

I looked once at the source code for it and came to a conclusion that it was not.

Look at JodaTime timezone class. It says in javadoc that it's thread-safe and immutable.

Answer 2

You are not modifying your TimeZone, so your code should be thread safe regardless of whether the underlying implementation of TimeZone is thread safe (with the exception of static methods, like (getTimeZone/getDefault/setDefault).

Answer 3

This appears to be OK. If you were relying on TimeZone.getDefault() that would be a different story. As another thread could potentially be calling TimeZone.setDefault().

Answer 4

There is no explicit documentation that states TimeZone is thread-safe, so the safest route is assume that it isn't thread safe.

The TimeZone class has two instance mutators, relating to ID and its GMT offset. Common sense would say that Calendar.getInstance and SimpleDateFormat have no business modifying TimeZone object state (in the first case, it's being used as a look-up key, and in the second, as formatting context).

Common sense or certainty - your choice.

Answer 5

It is not.

And you don't need it. You code uses it as:

final TimeZone tz = TimeZone.getTimeZone("GMT");
 ......
// thread 1 SimpleDateFormat instance
sdf.setTimeZone(tz);

// thread 2 SimpleDateFormat instance
sdf.setTimeZone(tz);

You have two threads using the same time zone, but since you are not modifying it you don't need it to be thread safe.

The only thing that you can modify is the ID, but even then you're ok, for the rest of the attributes are read-only

The only way you can get into trouble is by changing the id and caching your self the timezone, if you get it always from the TimeZone.getTimeZone() you are safe too, because that method is thread safe.