Why Is Subtracting These Two Times in 1927 Giving A Strange Result

Question

If I run the following program  which parses two date strings referencing times 1 second apart and compares them  public static void main String   args  throws ParseException       SimpleDateFormat sf   new SimpleDateFormat  quot yyyy-MM-dd HH mm ss quot          String str3    quot 1927-12-31 23 54 07 quot         String str4    quot 1927-12-31 23 54 08 quot         Date sDt3   sf parse str3         Date sDt4   sf parse str4         long ld3   sDt3 getTime    1000        long ld4   sDt4 getTime    1000      System out println ld4-ld3      The output is  353  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 1 second later  String str3    quot 1927-12-31 23 54 08 quot     String str4    quot 1927-12-31 23 54 09 quot      Then ld4-ld3 will be 1   Java version  java version  quot 1 6 0 22 quot  Java TM  SE Runtime Environment  build 1 6 0 22-b04  Dynamic Code Evolution Client VM  build 0 2-b02-internal  19 0-b04-internal  mixed mode   Timezone  TimeZone getDefault       sun util calendar ZoneInfo id  quot Asia Shanghai quot   offset 28800000 dstSavings 0  useDaylight false  transitions 19  lastRule null   Locale Locale getDefault     zh CN

User · Answer

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

User · Answer

As explained by others  there s a time discontinuity there  There are two possible timezone offsets for 1927-12-31 23 54 08 at Asia Shanghai  but only one offset for 1927-12-31 23 54 07  So  depending on which offset is used  there s either a one second difference or a 5 minutes and 53 seconds difference   This slight shift of offsets  instead of the usual one-hour daylight savings  summer time  we are used to  obscures the problem a bit   Note that the 2013a update of the timezone database moved this discontinuity a few seconds earlier  but the effect would still be observable   The new java time package on Java 8 let use see this more clearly  and provide tools to handle it  Given   DateTimeFormatterBuilder dtfb   new DateTimeFormatterBuilder    dtfb append DateTimeFormatter ISO LOCAL DATE   dtfb appendLiteral       dtfb append DateTimeFormatter ISO LOCAL TIME   DateTimeFormatter dtf   dtfb toFormatter    ZoneId shanghai   ZoneId of  Asia Shanghai     String str3    1927-12-31 23 54 07     String str4    1927-12-31 23 54 08      ZonedDateTime zdt3   LocalDateTime parse str3  dtf  atZone shanghai   ZonedDateTime zdt4   LocalDateTime parse str4  dtf  atZone shanghai    Duration durationAtEarlierOffset   Duration between zdt3 withEarlierOffsetAtOverlap    zdt4 withEarlierOffsetAtOverlap      Duration durationAtLaterOffset   Duration between zdt3 withLaterOffsetAtOverlap    zdt4 withLaterOffsetAtOverlap       Then durationAtEarlierOffset will be one second  while durationAtLaterOffset will be five minutes and 53 seconds   Also  these two offsets are the same      Both have offsets  08 05 52 ZoneOffset zo3Earlier   zdt3 withEarlierOffsetAtOverlap   getOffset    ZoneOffset zo3Later   zdt3 withLaterOffsetAtOverlap   getOffset      But these two are different       08 05 52 ZoneOffset zo4Earlier   zdt4 withEarlierOffsetAtOverlap   getOffset         08 00 ZoneOffset zo4Later   zdt4 withLaterOffsetAtOverlap   getOffset      You can see the same problem comparing 1927-12-31 23 59 59 with 1928-01-01 00 00 00  though  in this case  it is the earlier offset that produces the longer divergence  and it is the earlier date that has two possible offsets   Another way to approach this is to check whether there s a transition going on  We can do this like this      Null ZoneOffsetTransition zot3   shanghai getRules   getTransition ld3 toLocalDateTime       An overlap transition ZoneOffsetTransition zot4   shanghai getRules   getTransition ld3 toLocalDateTime     You can check whether the transition is an overlap where there s more than one valid offset for that date time or a gap where that date time is not valid for that zone id - by using the isOverlap   and isGap   methods on zot4   I hope this helps people handle this sort of issue once Java 8 becomes widely available  or to those using Java 7 who adopt the JSR 310 backport

User · Answer

As others said  it s a time change in 1927 in Shanghai  It was 23 54 07 in Shanghai  in the local standard time  but then after 5 minutes and 52 seconds  it turned to the next day at 00 00 00  and then local standard time changed back to 23 54 08  So  that s why the difference between the two times is 343 seconds  not 1 second  as you would have expected  The time can also mess up in other places like the US  The US has Daylight Saving Time  When the Daylight Saving Time starts the time goes forward 1 hour  But after a while  the Daylight Saving Time ends  and it goes backward 1 hour back to the standard time zone  So sometimes when comparing times in the US the difference is about 3600 seconds not 1 second  But there is something different about these two-time changes  The latter changes continuously and the former was just a change  It didn t change back or change again by the same amount  It s better to use UTC unless if needed to use non-UTC time like in display

User · Answer

I m sorry to say  but the time discontinuity has moved a bit in  JDK 6 two years ago  and in JDK 7 just recently in update 25   Lesson to learn  avoid non-UTC times at all costs  except maybe for display

User · Answer

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

User · Answer

IMHO the pervasive  implicit localization in Java is its single largest design flaw  It may be intended for user interfaces  but frankly  who really uses Java for user interfaces today except for some IDEs where you can basically ignore localization because programmers aren t exactly the target audience for it  You can fix it  especially on Linux servers  by   export LC ALL C TZ UTC set your system clock to UTC never use localized implementations unless absolutely necessary  ie for display only   To the Java Community Process members I recommend   make localized methods  not the default  but require the user to explicitly request localization  use UTF-8 UTC as the FIXED default instead because that s simply the default today  There is no reason to do something else  except if you want to produce threads like this   I mean  come on  aren t global static variables an anti-OO pattern  Nothing else is those pervasive defaults given by some rudimentary environment variables

User · Answer

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

User · Answer

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  History has changed again     In TZDB 2014f  the time of the change has moved to 1900-12-31  and it s now a mere 343 second change  so the time between t and t 1 is 344 seconds  if you see what I mean    EDIT  To answer a question 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

User · Answer

Instead of converting each date  you can use the following code    long difference    sDt4 getTime   - sDt3 getTime      1000  System out println difference     And then see that the result is   1

User · Answer

To avoid that issue  when incrementing time you should convert back to UTC and then add or subtract  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

[java] Why Is Subtracting These Two Times (in 1927) Giving A Strange Result?

Examples related to java

Examples related to date

Examples related to timezone