Why is subtracting these two times (in 1927) giving a strange result?
If I run the following program, which parses two date strings referencing times one second apart and compares them:

The output is:

Why is ld4-ld3 not 1 (as I would expect from the one-second difference in the times), but 353?

If I change the dates to times one second later:

Then ld4-ld3 will be 1


Java version:

improve this question | comment
Maya Gaylord Created at: 2013-11-13 17:07:52 UTC By Maya Gaylord
What locale are you running this in? It may be related to some daylight saving issue. - Alexzander Kunze
Did you really stumble upon that exact situation in a real-life scenario or was this question only meant to be a puzzler -- just for the fun of it ? - Haskell Maggio
@Costi Ciudatu: FWIW, I could easily imagine this coming up as the result of reducing a larger bug -- i.e., "Why are these two dates a year apart not exactly a year apart?" - Chandler Von
It seems you knew the exact date/time to force the strange behaviour. - Russell Hane
originally posted as Oracle Bug ID 7070044 on Jul 23 `11 - Ezra Ziemann
6 Answers
Instead of converting each date in long you use the following code 

long i = (sDt4.getTime() - sDt3.getTime()) / (1000);

And see the result is:


It's a time zone change on December 31st in Shanghai.

See this page for details of 1927 in Shanghai. Basically at midnight at the end of 1927, the clocks went back 5 minutes and 52 seconds. So "1927-12-31 23:54:08" actually happened twice, and it looks like Java is parsing it as the later possible instant for that local date/time - hence the difference.

Just another episode in the often weird and wonderful world of time zones.

EDIT: Stop press! History changes...

The original question would no longer demonstrate quite the same behaviour, if rebuilt with  version 2013a of TZDB. In 2013a, the result would be 358 seconds, with a transition time of 23:54:03 instead of 23:54:08.

I only noticed this because I'm collecting questions like this in Noda Time, in the form of unit tests... The test has now been changed, but it just goes to show - not even historical data is safe.

EDIT: To answer Ken Kin's question around a transition at 1900... it looks like the Java time zone implementation treats all time zones as simply being in their standard time for any instant before the start of 1900 UTC:

import java.util.TimeZone;

public class Test {
    public static void main(String[] args) throws Exception {
        long startOf1900Utc = -2208988800000L;
        for (String id : TimeZone.getAvailableIDs()) {
            TimeZone zone = TimeZone.getTimeZone(id);
            if (zone.getRawOffset() != zone.getOffset(startOf1900Utc - 1)) {

The code above produces no output on my Windows machine. So any time zone which has any offset other than its standard one at the start of 1900 will count that as a transition. TZDB itself has some data going back earlier than that, and doesn't rely on any idea of a "fixed" standard time (which is what getRawOffset assumes to be a valid concept) so other libraries needn't introduce this artificial transition.
I ran your code, the output is:





$ java -version
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.7) (fedora-
OpenJDK Client VM (build 19.0-b09, mixed mode)

When incrementing time you should convert back to UTC and then add or subtract. Use the local time only for display.

This way you will be able to walk through any periods where hours or minutes happen twice.

If you converted to UTC, add each second, and convert to local time for display. You would go through 11:54:08 p.m. LMT - 11:59:59 p.m. LMT and then 11:54:08 p.m. CST - 11:59:59 p.m. CST.
You've encountered a local time discontinuity:

  When local standard time was about to reach Sunday, 1. January 1928,
  00:00:00 clocks were turned backward 0:05:52 hours to Saturday, 31.
  December 1927, 23:54:08 local standard time instead

This is not particularly strange and has happened pretty much everywhere at one time or another as timezones were switched or changed due to political or administrative actions.
The moral of this strangeness is:

Use dates and times in UTC wherever possible.
If you can not display a date or time in UTC, always indicate the time-zone.
If you can not require an input date/time in UTC, require an explicitly indicated time-zone.
Your Answer