Introduction

DateFormat and its common subclass SimpleDateFormat are mutable and not thread-safe. If several threads share one formatter instance, they can corrupt each other's intermediate state and produce wrong dates, parse failures, or exceptions that are hard to reproduce consistently.

Why DateFormat Breaks Under Concurrency

The problem is not just that the class formats text. The formatter keeps mutable internal objects such as a Calendar and number-formatting state while it parses and formats values. If two threads use the same formatter at the same time, those internal fields can be modified mid-operation.

A simple unsafe example:

1import java.text.SimpleDateFormat;
2import java.util.Date;
3
4public class UnsafeFormatter {
5    private static final SimpleDateFormat FORMAT =
6        new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
7
8    public static void main(String[] args) {
9        Runnable task = () -> {
10            for (int i = 0; i < 1000; i++) {
11                String value = FORMAT.format(new Date());
12                System.out.println(value);
13            }
14        };
15
16        new Thread(task).start();
17        new Thread(task).start();
18    }
19}

This may appear to work for a while, then fail unpredictably when thread timing changes.

What Kind of Bugs It Causes

Because the corruption happens inside shared mutable state, the symptoms can vary:

• dates formatted with incorrect fields
• parsing that returns the wrong timestamp
• intermittent exceptions such as NumberFormatException
• failures that disappear in local testing and reappear under load

That variability is what makes the issue dangerous. The bug is real even if it does not happen on every run.

Safe Alternatives

The best long-term answer in modern Java is to use the java.time API. DateTimeFormatter is immutable and thread-safe.

1import java.time.LocalDateTime;
2import java.time.format.DateTimeFormatter;
3
4public class SafeFormatter {
5    private static final DateTimeFormatter FORMATTER =
6        DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss");
7
8    public static void main(String[] args) {
9        String value = LocalDateTime.now().format(FORMATTER);
10        System.out.println(value);
11    }
12}

If you are stuck with older APIs, create a new SimpleDateFormat per use or isolate one formatter per thread:

1import java.text.SimpleDateFormat;
2
3public class ThreadLocalFormatter {
4    private static final ThreadLocal<SimpleDateFormat> FORMAT =
5        ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd"));
6}

Synchronizing access is another option, but it serializes callers and usually makes less sense than switching to a safer API.

Migrate Gradually When Necessary

Legacy code often uses Date, Calendar, and SimpleDateFormat together. If a full migration is not possible right away, start by replacing shared static formatter instances first. That removes the concurrency bug without forcing a complete date-time rewrite in one step.

Then move outward toward Instant, LocalDate, ZonedDateTime, and DateTimeFormatter where practical. Each step reduces the amount of mutable date-handling code in the system.

Common Pitfalls

The biggest mistake is keeping a static final SimpleDateFormat and assuming final makes it safe. final only means the reference cannot point somewhere else. It does not make the formatter immutable.

Another common issue is adding synchronized around one code path while other code paths still share the same formatter without locking. Partial fixes do not remove the race.

People also underestimate how subtle the symptoms are. Wrong dates are often more damaging than visible crashes because they can slip into logs, reports, or persisted records unnoticed.

Finally, if you are on Java 8 or later, do not keep adding new SimpleDateFormat usage. Prefer java.time for new code.

Summary

• 'DateFormat and SimpleDateFormat are not thread-safe because they use shared mutable state.'
• Sharing one formatter instance across threads can cause wrong output, parse failures, and intermittent exceptions.
• 'final does not make a formatter thread-safe.'
• Prefer DateTimeFormatter from java.time for modern Java code.
• If you must keep SimpleDateFormat, avoid shared instances or isolate them per thread.