Why Java’s SimpleDateFormat Adds 5 min 43 sec? Uncovering Hidden Timezone History

Unexpected 5 min 43 sec Offset in Java Date Formatting

When parsing the date 1900-01-01 08:00:00 with SimpleDateFormat, the program prints 1900-01-01 08:05:43 instead of the expected 1900-01-01 08:00:00.

public class MainTest {
    public static void main(String[] args) throws Exception {
        SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
        Date date = simpleDateFormat.parse("1900-01-01 08:00:00");
        System.out.println(simpleDateFormat.format(date));
    }
}

The discrepancy is caused by historic timezone data for Shanghai. In 1900 the official offset was UTC +08:05:43, which the JDK’s timezone database (TZDB) applied.

The timezone offset was UTC +8:05:43 hours all of the period.

Later JDK bug reports (e.g., JDK‑8266262 ) and older Stack Overflow questions ( why‑is‑subtracting‑these‑two‑times‑in‑1927‑giving‑a‑strange‑result ) discuss similar anomalies.

In 1927 Shanghai’s clocks were set back by 5 min 52 sec at midnight, causing a “duplicate” 23:54:08 timestamp. Different TZDB releases (2013a, 2014f) handle this transition differently, leading to variations such as 353 seconds, 358 seconds, or 343 seconds offsets.

No further time changes in 1927 in Shanghai

The JDK ultimately normalises all moments before 1900 to UTC and then adds the historic offset, which explains the observed 5 min 43 sec extra.

Older bug entries (e.g., JDK‑6281408 from 2005) confirm that the behaviour is intentional and will not be fixed to preserve compatibility.

Thus the “mystery” offset is a consequence of historical timezone definitions stored in the IANA TZ database.