Java 8
LocalDateTime
TemporalAccessor
Parsing Error
Programming Troubleshooting

Unable to obtain LocalDateTime from TemporalAccessor when parsing LocalDateTime (Java 8)

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Introduction

The exception "Unable to obtain LocalDateTime from TemporalAccessor" means Java parsed something, but not enough temporal fields were present to build a full LocalDateTime. LocalDateTime requires both a calendar date and a time of day, so parsing only half the information is the most common cause of this error.

Why the Exception Happens

DateTimeFormatter.parse(...) returns a generic TemporalAccessor. That parsed result might contain a date only, a time only, or some other partial temporal state. LocalDateTime.from(...) succeeds only if the parsed data includes all the fields needed for a full local date-time.

This fails because the input has a date but no time:

java
1import java.time.LocalDateTime;
2import java.time.format.DateTimeFormatter;
3
4DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd");
5LocalDateTime value = LocalDateTime.from(formatter.parse("2025-09-15"));

The formatter parsed the string correctly, but the result only has year, month, and day. There is no hour or minute information, so Java cannot create a LocalDateTime.

Parse to the Type That Matches the Input

The cleanest fix is to parse into the temporal type that actually matches the data.

If the string only has a date, use LocalDate:

java
1import java.time.LocalDate;
2import java.time.format.DateTimeFormatter;
3
4DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd");
5LocalDate date = LocalDate.parse("2025-09-15", formatter);
6System.out.println(date);

If the string includes both date and time, parse directly to LocalDateTime:

java
1import java.time.LocalDateTime;
2import java.time.format.DateTimeFormatter;
3
4DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss");
5LocalDateTime value = LocalDateTime.parse("2025-09-15 13:45:30", formatter);
6System.out.println(value);

This direct parse is clearer than calling formatter.parse(...) and then converting manually.

Converting from Other Temporal Types

Another version of the same problem happens when the source type is not really a local date-time. For example, Instant represents a point on the UTC timeline, not a wall-clock value in a particular region.

java
1import java.time.Instant;
2import java.time.LocalDateTime;
3
4Instant now = Instant.now();
5LocalDateTime value = LocalDateTime.from(now); // throws

To convert an Instant to LocalDateTime, provide a time zone.

java
1import java.time.Instant;
2import java.time.LocalDateTime;
3import java.time.ZoneId;
4
5Instant now = Instant.now();
6LocalDateTime value = LocalDateTime.ofInstant(now, ZoneId.of("America/Toronto"));
7System.out.println(value);

The zone is required because the same instant maps to different local clock times in different regions.

Build Missing Parts Explicitly When Appropriate

Sometimes the input really is only a date, but your application still wants a LocalDateTime. In that case, choose the missing time explicitly instead of forcing the parser to invent one.

java
1import java.time.LocalDate;
2import java.time.LocalDateTime;
3import java.time.LocalTime;
4
5LocalDate date = LocalDate.parse("2025-09-15");
6LocalDateTime startOfDay = date.atStartOfDay();
7LocalDateTime noon = LocalDateTime.of(date, LocalTime.NOON);
8
9System.out.println(startOfDay);
10System.out.println(noon);

This is safer because it makes the default time a business decision rather than a hidden parser assumption.

Read the Formatter Pattern Carefully

A mismatched pattern can produce the same exception indirectly. If the input string contains time data but the formatter pattern omits it, the parse succeeds only partially. The final conversion then fails later. That is why formatter patterns should always be reviewed alongside the input examples, not in isolation.

Common Pitfalls

Parsing into TemporalAccessor first and then forcing LocalDateTime.from(...) is often more error-prone than parsing directly into the final type.

Assuming Instant or another temporal type can always be converted directly to LocalDateTime ignores the need for time-zone context.

Using a formatter that matches only part of the input produces confusing downstream errors. Check the pattern before checking the conversion code.

Summary

  • 'LocalDateTime needs both date and time fields.'
  • Parse directly to LocalDate, LocalTime, or LocalDateTime based on the input you actually have.
  • When converting from Instant, provide a ZoneId.
  • If part of the date-time is missing, supply it explicitly instead of relying on accidental parser behavior.

Course illustration
Course illustration

All Rights Reserved.