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:
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:
If the string includes both date and time, parse directly to LocalDateTime:
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.
To convert an Instant to LocalDateTime, provide a time zone.
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.
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
- '
LocalDateTimeneeds both date and time fields.' - Parse directly to
LocalDate,LocalTime, orLocalDateTimebased on the input you actually have. - When converting from
Instant, provide aZoneId. - If part of the date-time is missing, supply it explicitly instead of relying on accidental parser behavior.

