Formatting and Parsing of Large ISO-8601 Dates is inconsistent

[DavTurns]

Search before asking

• I searched in the issues and found nothing similar.

Describe the bug

As already addressed in #2167 Jackson adds a leading “+” for ISO-8601 dates (expanded representation) when the year value is greater than 9999, and “–” for BCE dates, during serialization.
However, deserialization of these ISO-8601 dates does not work in reverse.

Version Information

2.19.2

Reproduction

import com.fasterxml.jackson.databind.util.StdDateFormat;

import java.text.ParseException;
import java.util.Date;

class StdDateFormatTest {
    public static void main(String[] args) throws ParseException {
        StdDateFormat formatter = new StdDateFormat();
        Date dateFuture = new Date(Long.MAX_VALUE);
        Date datePast = new Date(Long.MIN_VALUE);
        
        //this part works fine
        String dateFutureAsString = formatter.format(dateFuture);
        String datePastAsString = formatter.format(datePast);

        // The test fails because parsing back throws ParseException
        Date parsedBackDateFuture = formatter.parse(dateFutureAsString);
        Date parsedBackDatePast = formatter.parse(datePastAsString);

        assert parsedBackDateFuture.getTime() == dateFuture.getTime();
        assert parsedBackDatePast.getTime() == datePast.getTime();
    }
}

Expected behavior

All formatted dates are being parsed back correctly.

Additional context

Location:

jackson-databind/src/main/java/tools/jackson/databind/util/StdDateFormat.java

Line 533 in 37b593e

&& Character.isDigit(dateStr.charAt(0))

[cowtowncoder]

StdDateFormat is not part of the public API, as per Javadocs:

 * Jackson's internal {@link DateFormat} implementation used by standard Date
 * serializers and deserializers to implement default behavior: does <b>NOT</b>
 * fully implement all aspects expected by {@link DateFormat} and as a consequence
 * <b>SHOULD NOT</b> to be used by code outside core Jackson databind functionality.

so the reproduction is not valid as-is (behavior is not guaranteed in any way, it's only to be used by databind itself).

But if this can be shown via public API we'd need test(s) showing the issue(s)?
So basically issue(s) with reading and/or writing of java.util.Date or java.util.Calendar values would be valid.

[DavTurns]

Thanks for the clarification, I have reproduced the issue again using only the public Jackson API,
and without touching StdDateFormat directly.

By disabling WRITE_DATES_AS_TIMESTAMPS, ObjectMapper switches to its
ISO-8601 date format (as documented).

import com.fasterxml.jackson.databind.ObjectMapper;
import com.fasterxml.jackson.databind.SerializationFeature;
import org.junit.jupiter.api.Test;

import java.util.Date;

import static org.junit.jupiter.api.Assertions.assertEquals;

public class MyTest {
    @Test
    void testDateRoundTripWithMaxValue() throws Exception {
        ObjectMapper mapper = new ObjectMapper()
                .disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS);

        Date original = new Date(Long.MAX_VALUE);
        String json = mapper.writeValueAsString(original);
        Date parsed = mapper.readValue(json, Date.class);

        assertEquals(original.getTime(), parsed.getTime());
    }

    @Test
    void testDateRoundTripWithMinValue() throws Exception {
        ObjectMapper mapper = new ObjectMapper()
                .disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS);

        Date original = new Date(Long.MIN_VALUE);
        String json = mapper.writeValueAsString(original);
        Date parsed = mapper.readValue(json, Date.class);

        assertEquals(original.getTime(), parsed.getTime());
    }
}

[cowtowncoder]

Fixed for:

• 2.21.0
• 3.0.3