1

I'm trying to parse "1901-01-01T00:20:40.000+02:20:40" date but I'm getting the following error:

Cannot deserialize value of type java.util.Date from String "1901-01-01T00:20:40.000+02:20:40": not a valid representation (error: Failed to parse Date value '1901-01-01T00:20:40.000+02:20:40': Cannot parse date "1901-01-01T00:20:40.000+02:20:40":

I read it is a problem with java date format which is not able the pare old dates, is there something that I can do in order to fix this issue?

---- edit ----

until now, i deserialized lots of different dates from the last 20 years, and they all worked fine. It is a very simple object:

public class Record extends Docs {
    public Date published;
}

and

    results =
            given().
                    config(config).
                    log().ifValidationFails().
                    when().
                    get(lastUrlComponent).
                    then().
                    log().ifValidationFails().
                    statusCode(HttpStatus.SC_OK).
                    contentType(ContentType.JSON).
                    assertThat().body(matchesJsonSchemaInClasspath(jsonSchemaInClasspath)).
                    extract().
                    response().as(resultsClass);
}
Hovercraft Full Of Eels
  • 283,665
  • 25
  • 256
  • 373
Noy M
  • 303
  • 1
  • 4
  • 13
  • 1
    *"I read it is a problem with java date format which is not able the pare old dates"* -- please cite your source? No, Java can parse dates, old and new. The problem is in your code (which for some reason, you're not showing us). Side note: better to use the newer DateTime library than the old Date library, but not due to this non-issue. – Hovercraft Full Of Eels Aug 14 '22 at 11:45
  • 1
    So, the date String is part of a JSON String that you are deserializing? If so, what library are you using to deserialize the JSON? – Hovercraft Full Of Eels Aug 14 '22 at 12:07
  • I'm using rest assured. I tried now to change to DateTime and got the same error, it happens only for the old dates: no String-argument constructor/factory method to deserialize from String value ('1900-01-01T00:20:40.000+02:20:40') – Noy M Aug 14 '22 at 12:08
  • 1
    That's a very weird timezone. It's off by 2 hours, 20 minutes and 40 seconds from UTC? I'm not aware of any time parsing code that can handle second-offsets. – knittl Aug 14 '22 at 12:18
  • 1
    I share @knittl’s suspicion: some library you are using (directly or indirectly) does not expect seconds in the offset, `+02:20:40`, as is customary in old dates. – Ole V.V. Aug 14 '22 at 12:20
  • I strongly recommend you don’t use `Date`. That class is poorly designed and long outdated. Instead use `OffsetDateTime` from [java.time, the modern Java date and time API](https://docs.oracle.com/javase/tutorial/datetime/). I don’t expect it in itself to solve your problem, but I guess it’s worth trying. – Ole V.V. Aug 14 '22 at 12:23
  • Both the outdated `SimpleDateFormat` class and the classes of java.time can parse dates in 1901 and earlier (though some funny results come out of it sometimes). – Ole V.V. Aug 14 '22 at 12:26
  • 1
    Thank you all for the answers, I'll try with a valid offset and get back with an answer. Also, I will stop using `Date` and will change my dates to `OffsetDateTime` or `DateTime` – Noy M Aug 14 '22 at 12:26
  • 3
    According to [timeanddate.com](https://www.timeanddate.com/time/zone/israel/jerusalem) Jerusalem (in today’s Israel) was at the mentioned offset until Israel Standard Time was introduced from 1918. They refer to the old time as JMT, probably for Jerusalem Mean Time, that is, the mean solar time in Jerusalem. – Ole V.V. Aug 14 '22 at 12:39
  • 1
    Correction: Jerusalem on the border between Israel and the occupied territories. – Ole V.V. Aug 18 '22 at 17:38

3 Answers3

1

java.time

Never use the terrible legacy date-time classes such as Date & Calendar. Use only their successors, the modern java.time classes defined in JSR 310.

Offset-from-UTC

Your input is text in standard ISO 8601 format. That text contains a date, a time-of-day, and a number of hours-minutes-seconds offset from the temporal prime meridian of UTC.

OffsetDateTime

The appropriate class for such an input is OffsetDateTime. That class can directly parse inputs in ISO 8601 format. So no need to define a formatting pattern.

String input = "1901-01-01T00:20:40.000+02:20:40" ;
OffsetDateTime odt = OffsetDateTime.parse( input ) ;

Adjust to an offset of zero.

Instant instant = odt.toInstant() ;

See this code run live at Ideone.com.

odt.toString(): 1901-01-01T00:20:40+02:20:40

instant.toString(): 1900-12-31T22:00:00Z

Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154
0

It should follow steps bellow:

  1. Read it as String (It can work)

    private String published

  2. List item

  3. Define the date format

  4. Parse it to date by Java

I think it easier to make your application that can work

Thanh Nguyen Chi Song
  • 10
  • 1
    While it sounds like a way through, I would prefer to parse directly into an `OffsetDateTime` or other date-time type. I would not give up on this possibility until having researched it a lot more. – Ole V.V. Aug 14 '22 at 13:45
0

"1901-01-01T00:20:40.000+02:20:40" is not a valid offset - 2 hours, 20 minutes, and 40 seconds from UTC

Noy M
  • 303
  • 1
  • 4
  • 13
  • 1
    Wrong. The offset is *the* valid offset for Jerusalem back then. – Ole V.V. Nov 17 '22 at 11:49
  • 02:20:40? are you sure? – Noy M Nov 18 '22 at 13:42
  • 1
    I gave the link already in a comment under your question. I am repeating it here: [Time Changes in Jerusalem Over the Years](https://www.timeanddate.com/time/zone/israel/jerusalem). In the dropdown select "1900 -- 1924". Read (quote): *1900 — 1917 No changes, UTC +2:20:40 hours all of the period*. – Ole V.V. Nov 18 '22 at 15:42
  • It depends o how you define "valid", though. Your string attempts to be in [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601#Time_offsets_from_UTC) format, but the offset is not valid in ISO 8601. According to the link it should have format `±[hh]:[mm], ±[hh][mm], or ±[hh]`. So ISO 8601 is in conflict with reality when it comes to historic dates and times. – Ole V.V. Nov 18 '22 at 15:46