How to Fix Jackson JSON Parse Error Can not construct instance of java.time.LocalDate

1. Overview

When working with JSON in Java, Jackson usually handles Java 8 date and time types without much configuration. Yet, we can still encounter problems such as one of the common deserialization parse errors:

JSON parse error: Can not construct instance of java.time.LocalDate:
no String-argument constructor/factory method to deserialize from String value

In newer Jackson versions, the error text takes another form:

Cannot deserialize value of type java.time.LocalDate from String

Although the wording differs slightly, both errors indicate that Jackson is unable to convert the JSON value into a LocalDate or LocalDateTime.

In this tutorial, we’ll explore the JSON deserialization exception and ways around it. First, we demonstrate the issue with an example. After that, we go through different reasons for the problem at hand and how they can be addressed.

2. Understanding the Problem

Let’s write a basic User class:

public class User {

    private String name;
    private LocalDate dob;

    // getters and setters
}

Now, let’s assume we receive a matching JSON:

{
  "name": "x",
  "dob": "2006-06-06"
}

Instead of successfully deserializing the JSON, Jackson throws an exception similar to:

Can not construct instance of java.time.LocalDate:
no String-argument constructor/factory method to deserialize from String value

Notably, the JSON data appears to be valid, because the date already follows the ISO-8601 format expected by LocalDate. The problem usually isn’t the JSON itself but the configuration of Jackson. In fact, the root cause may be a missing Java Time module, an unsupported date format, or using the wrong Java date-time type for the incoming JSON.

3. Verify Jackson Version

Support for the Java Time API has evolved considerably across Jackson releases. Before delving into specific technical issues and code changes, we might consider the versions we’re using.

In Jackson 2.x, Java Time support is provided by the separate jackson-datatype-jsr310 module. In Jackson 3.x, this support is built into jackson-databind, so separate module registration isn’t required.

If the project uses an outdated Jackson version, upgrading Jackson may resolve deserialization issues without any code changes. When it comes to Jackson 2.x, we should also verify that the Java Time module is present and properly configured.

4. Ensure Java Time Support

The most common cause for the JSON error is that the Jackson configuration doesn’t support the Java 8 Date and Time API.

Unlike older types such as java.util.Date, classes like LocalDate, LocalDateTime, and Instant are provided through the Jackson Java Time module.

If this module is missing, Jackson attempts to instantiate LocalDate like a regular Java object. Since LocalDate has no default constructor or string constructor, deserialization fails.

So, assuming we decide on Jackson 2.x, let’s include the Java Time module dependency:

<dependency>
    <groupId>com.fasterxml.jackson.datatype</groupId>
    <artifactId>jackson-datatype-jsr310</artifactId>
    <version>2.22.1</version>
</dependency>

If an ObjectMapper is created manually, it should register the module:

ObjectMapper mapper = new ObjectMapper();
mapper.registerModule(new JavaTimeModule());

Still, Spring Boot performs this registration automatically when the module is present on the classpath.

5. Match JSON Date Format

Another common cause for JSON deserialization errors is the exact date format. If the incoming JSON doesn’t use the default ISO-8601 format expected by LocalDate and LocalDateTime, we might see an error.

For example, let’s see a JSON string that can’t be parsed automatically:

{
  "time": "10/20/2020 10:00:10 AM"
}

With the Java Time module registered, Jackson expects an ISO-8601 date-time for a LocalDateTime field by default:

2020-10-20T10:00:10

In such cases, when the JSON data uses another format, the field should specify the expected pattern:

public class ImportTrans {

    @JsonFormat(pattern = "M/d/yyyy h:mm:ss a")
    private LocalDateTime time;
}

However, this example also contains another hint. The JSON data can actually contain both a date and a time, while Java LocalDate fields only store a date.

6. Correct Java Time Type

LocalDate represents only a calendar date. In particular, it doesn’t contain any information about time of the day.

If the JSON data includes hours, minutes, or seconds, LocalDate is no longer the appropriate target type:

private LocalDate time;

Instead, we should probably use LocalDateTime:

private LocalDateTime time;

Furthermore, the matching format can then be declared with @JsonFormat:

@JsonFormat(pattern = "M/d/yyyy h:mm:ss a")
private LocalDateTime time;

Choosing the Java type that accurately represents the JSON payload is often the simplest solution.

7. LocalDateTime Has Similar Requirements

The same type of exception frequently appears when using LocalDateTime:

Can not deserialize value of type
java.time.LocalDateTime from String

Let’s consider the following JSON:

{
  "creationTime": "2016-06-16 06:56:00"
}

Same as before, since this format differs from the default ISO-8601 representation, Jackson requires an explicit pattern:

@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")
private LocalDateTime creationTime;

The ObjectMapper must also have the Java Time module registered, while the explicit pattern is still required for this non-ISO format.

8. Comparison

Now that we know different reasons for errors around parsing JSON with date-time values with Jackson, let’s see an overview of what we found out:

So, we can check the reference table whenever we encounter an unexpected error.

9. Conclusion

In this article, we explored the error stating that Jackson can’t construct an instance of LocalDate or LocalDateTime.

Specifically, we established that it generally indicates Jackson can’t determine how to convert the incoming JSON into a Java date-time object.

In conclusion, once the Java type, JSON payload format, and Jackson configuration are aligned, such deserialization errors should disappear and Java Time types should be handled transparently.