Fixing UnsupportedTemporalTypeException: Unsupported Field: InstantSeconds

Last updated: July 1, 2024

Written by: Abderrahim Azhrioun

Reviewed by: Luis Javier Peris

Java Dates

Refactor Java code safely — and automatically — with OpenRewrite.

Refactoring big codebases by hand is slow, risky, and easy to put off. That’s where OpenRewrite comes in. The open-source framework for large-scale, automated code transformations helps teams modernize safely and consistently.

Each month, the creators and maintainers of OpenRewrite at Moderne run live, hands-on training sessions — one for newcomers and one for experienced users. You’ll see how recipes work, how to apply them across projects, and how to modernize code with confidence.

Join the next session, bring your questions, and learn how to automate the kind of work that usually eats your sprint time.

Regression testing is an important step in the release process, to ensure that new code doesn't break the existing functionality. As the codebase evolves, we want to run these tests frequently to help catch any issues early on.

The best way to ensure these tests run frequently on an automated basis is, of course, to include them in the CI/CD pipeline. This way, the regression tests will execute automatically whenever we commit code to the repository.

In this tutorial, we'll see how to create regression tests using Selenium, and then include them in our pipeline using GitHub Actions:, to be run on the LambdaTest cloud grid:

>> How to Run Selenium Regression Tests With GitHub Actions

1. Overview

When working with dates, we often leverage the Date-Time API. However, manipulating or accessing temporal data may lead to errors and exceptions when done improperly. One such specific exception is UnsupportedTemporalTypeException: “Unsupported Field: InstantSeconds” which typically denotes that the field InstantSeconds isn’t supported by the specified temporal object.

So, in this short tutorial, we’ll learn how to avoid this exception when working with the Date-Time API.

2. Practical Example

Before diving into the solution, let’s use a practical example to understand the root cause of the exception.

According to the documentation, UnsupportedTemporalTypeException signals that a ChronoField or ChronoUnit isn’t supported. In other words, the exception occurs when an unsupported field is used with a temporal object that doesn’t support that specific field.

Typically, the stack trace “Unsupported Field: InstantSeconds” says it all. It indicates that there’s something wrong with the field InstantSeconds which represents the concept of the sequential count of seconds from the epoch.

In short, not all temporal objects provided by the Date-Time API support this field. For example, attempting to apply operations involving InstantSeconds to LocalDateTime, LocalDate, and LocalTime results in UnsupportedTemporalTypeException.

Now, let’s see how to reproduce the exception in practice. To do so, we’ll try to convert a LocalDateTime to Instant:

@Test
void givenLocalDateTime_whenConvertingToInstant_thenThrowException() {
    assertThatThrownBy(() -> {
        LocalDateTime localDateTime = LocalDateTime.now();
        long seconds = localDateTime.getLong(ChronoField.INSTANT_SECONDS);
        Instant instant = Instant.ofEpochSecond(seconds);
    }).isInstanceOf(UnsupportedTemporalTypeException.class)
        .hasMessage("Unsupported field: InstantSeconds");
}

As we can see, the test failed because we attempted to access ChronoField.INSTANT_SECONDS using an instance of LocalDateTime.

In short, LocalDateTime doesn’t support INSTANT_SECONDS which denotes a single specific instant because the same LocalDateTime object could represent multiple different instants depending on the time zone. For instance, “2024-06-22T11:20:33” in New York differs from “2024-06-22T11:20:33” in Tokyo.

3. Solution

As we noted earlier, the main reason why LocalDateTime doesn’t support ChronoField.INSTANT_SECONDS is that it lacks sufficient information about the time zone to determine the exact instantaneous point on the global timeline.

So, the easiest solution would be to set the time zone before converting the LocalDateTime to Instant. For that purpose, we can use the ZonedDateTime class:

@Test
void givenLocalDateTime_whenConvertingUsingTimeZone_thenDoNotThrowException() {
    LocalDateTime localDateTime = LocalDateTime.now();
    ZonedDateTime zonedDateTime = localDateTime.atZone(ZoneId.systemDefault());

    assertThatCode(() -> {
        Instant instant = zonedDateTime.toInstant();
    }).doesNotThrowAnyException();
}

Here, we used the atZone() method to return a ZonedDateTime object formed from the given LocalDateTime at the specified time zone. Then, we called toInstant() to calculate the instant represented by the date-time based on the provided time zone.

4. Conclusion

In this short article, we learned the root cause behind UnsupportedTemporalTypeException. Furthermore, we saw how to reproduce and fix it in practice.

The code backing this article is available on GitHub. Once you're logged in as a Baeldung Pro Member, start learning and coding on the project.