Search code examples
javadatejackson-databind

Why is this converted Jackson time different to expected Unix time?

Edit: It turns out the problem is not about Jackson, but about time adjustment in Thailand on 1 April 1920.

How does com.fasterxml.jackson.databind.ObjectMapper works? I thought it used Unix timestamp.

I tried converting a java.util.Date with mapper.writeValueAsString().

When I convert the string back to Date with mapper.readerFor(Date.class).readValue(), the result is correct.

However, when I trying removing the last 3 digits and and put the same string into some converter websites, the result is off for some minutes and seconds.

Please see the code below.

Date wayBack = new SimpleDateFormat("yyyy-MM-dd").parse("1900-01-31");
System.out.println(wayBack); // Wed Jan 31 00:00:00 ICT 1900
ObjectMapper mapper = new ObjectMapper();
System.out.println(mapper.writeValueAsString(wayBack)); // -2206420924000
Date deserialised = mapper.readerFor(Date.class).readValue(mapper.writeValueAsString(wayBack));
System.out.println(deserialised); // Wed Jan 31 00:00:00 ICT 1900

Below is a screenshot from http://www.onlineconversion.com/unix_time.htm

unix time converter

Please note that 7-hour off is expected because of my timezone but I don't understand the 17:56 minutes different.

Solution

  • EDIT - Here is my attempt to provide a better answer than my first one.

    Background

    Before looking at the code in the question, some background notes:

    The epoch value (in seconds) at midnight 31st Jan 1900 in Bangkok is -2206420924:

    LocalDateTime localDateTime = LocalDateTime.parse("1900-01-31T00:00:00");
ZoneId z = ZoneId.of("Asia/Bangkok");
ZonedDateTime ict_1 = ZonedDateTime.of(localDateTime, z);
System.out.println("Epoch seconds: " + ict_1.toEpochSecond());
System.out.println("ICT datetime : " + ict_1);

    The above prints this:

    Epoch seconds: -2206420924
ICT datetime : 1900-01-31T00:00+06:42:04[Asia/Bangkok]

    The epoch value (in seconds) for UTC midnight on the same date is -1570060800:

    ZonedDateTime utcDateTime = ZonedDateTime.parse("1900-01-31T00:00:00Z");
System.out.println("Epoch seconds: " + utcDateTime.toEpochSecond());
System.out.println("UTC datetime : " + utcDateTime);

    The above prints this:

    Epoch seconds: -2206396800
UTC datetime : 1900-01-31T00:00Z

    The time at midnight in Bangkok on 31st January 1900 was 24,124 seconds further into the past than the time at midnight in Greenwich, UK (the prime meridian - or UTC).

    That is to say, on that date Bangkok was 6 hours, 42 minutes and 4 seconds ahead of UTC time (or GMT as I believe it was then called - as UTC had not been established at that time).

    The Specific Code in the Question

    First, I changed my default time zone to match the one used in the question:

    System.setProperty("user.timezone", "Asia/Bangkok");

    The below line from the question does the following:

    (1) The SimpleDateFormat constructor, in which the date format string does not specify a locale, uses the default locale.

    (2) Then the parse() method creates the Date object:

    Date wayBack = new SimpleDateFormat("yyyy-MM-dd").parse("1900-01-31");

    At this point we can check the date object:

    System.out.println(wayBack);
System.out.println(wayBack.getTime());

    This prints the following:

    Wed Jan 31 00:00:00 ICT 1900
-2206420924000 // epoch milliseconds

    This matches what we saw earlier, in the background section.

    When you use an online tool such as the one mentioned in the question, you will see the above milliseconds value reported as the following GMT (UTC) datetime:

    GMT: Tuesday, January 30, 1900 5:17:56 PM

    For the above output I used this tool.

    Again, this is what we expect - when it's midnight in Bangkok, it's still the afternoon of the day before in Greenwich, UK.

    The remainder of the code (including the Jackson object mapper transformations) are all subject to this initial set-up of your Date object.

    For the question: "How does com.fasterxml.jackson.databind.ObjectMapper works? I thought it used Unix timestamp." It shows the same behavior as the core Java date object. I believe your assumption is correct.

    Regarding the Unusual Offset

    Regarding the ICT offset of +06:42:04 shown above:

    On April 1st 1920, an adjustment was made to the local ICT (Indochina Time), to align it with UTC time (with an offset of +7 hours, as you note). The local clocks were set forward by 17 minutes and 56 seconds, to round up the UTC (GMT) offset to 7 hours.

    See this link for a specific reference to the 17 minutes & 56 seconds change.

    This is why you will not see that unusual offset from April 1920 onwards.

    Further Links

    See this answer regarding the newer java.time classes which should be used instead of java.util.Date.

    See this question and its answers for a related deep-dive into the topic of historic time zone adjustments.