ISO-8601 change prevents parsing negative timestamps (dates before 1970)

[thomaswoeckinger]

Search before asking

• I searched in the issues and found nothing similar.

Describe the bug

Due to changes of #5429 a negative timestamp, e.g. -1383043669935, would be treated as ISO8601in method looksLikeISO8601 of StdDateFormat.
In my opinion the given string must not be treated as ISO-8601 if it consist of a - and only digits.

Version Information

2.21.1

Reproduction

Create a negative timestamp (12.5.1926)
Try parsing it as Date

Expected behavior

It should be possible to parse negative timestamps

Additional context

No response

[pjfanning]

Probably a bug with java.util.Date support. Would need to be fixed, if so. Have you tried changing to java.time.LocalDate as a workaround?

[thomaswoeckinger]

Probably a bug with java.util.Date support. Would need to be fixed, if so. Have you tried changing to java.time.LocalDate as a workaround?

No this is strictly not depending on LocalDate (Line 616 to 619):

           if (c == '+' || c == '-') {
                return (dateStr.length() >= 11)
                    && Character.isDigit(dateStr.charAt(1));
            }

as you can see it is simply not enough to check first two characters and the overall length to be greater than 11.

[yawkat]

Sorry @pjfanning , I also used this as an agent exercise 😄

[yawkat]

I'll leave the decision which PR is better to you

[pjfanning]

@yawkat I'm out and about. So your PR is fine with me.

[pjfanning]

One potential workaround is to annotate your Date field with something like:
@JsonFormat(shape=JsonFormat.Shape.NUMBER_INT) or JsonFormat.Shape.NUMBER works too

This tells Jackson to expect Unix style Dates represented as integers/longs. There is no ambiguity then about whether the number could be compact ISO-8601 Date that omits the '-' separators (eg 20260305).

[cowtowncoder]

@pjfanning JsonFormat.Shape would not affect case of "Number as String" which seems to be what happens here -- it would make serialization use timestamp but would not change deserialization. Question tho is why is someone serializing (negative) timestamps as JSON Strings instead of JSON Numbers.

Altho forcing serialization as JSON Number would work, if that is the root cause.