Welcome to Mobilarian Forum - Official Symbianize forum.

Join us now to get access to all our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, and so, so much more. It's also quick and totally free, so what are you waiting for?

[solved] Why is subtracting these two times (in 1927) giving a strange result?

M 0


Jun 25, 2014
Reaction score
10 years of service
It's a time zone change on December 31st in Shanghai.
Please, Log in or Register to view URLs content!
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 the press! History changes...
The original question would no longer demonstrate quite the same behaviour, if rebuilt with version 2013a of
Please, Log in or Register to view URLs content!
. 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
Please, Log in or Register to view URLs content!
... The test has now been changed, but it just goes to show - not even historical data is safe.

EDIT: To answer
Please, Log in or Register to view URLs content!
around a transition at 1900... it looks like the Java timezone 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)) { System.out.println(id); } } }}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.
Top Bottom