---
title: "Why is subtracting these two times (in 1927) giving a strange result?"  
description: "Why is subtracting these two times (in 1927) giving a strange result?"  
author: "Royce Roy"  
published: 2015-05-01  
updated: 2015-05-02  
canonical: https://www.mindstick.com/forum/23176/why-is-subtracting-these-two-times-in-1927-giving-a-strange-result  
category: ".net"  
tags: ["java"]  
reading_time: 3 minutes  

---

# Why is subtracting these two times (in 1927) giving a strange result?

If I run the following [program](https://www.mindstick.com/blog/12337/scaling-up-your-mentorship-program), which parses two date [strings](https://www.mindstick.com/forum/161912/explain-the-python-strings) referencing times one second apart and compares them:

```
public static void main(String[] args) throws ParseException {    SimpleDateFormat sf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");      String str3 = "1927-12-31 23:54:07";      String str4 = "1927-12-31 23:54:08";      Date sDt3 = sf.parse(str3);      Date sDt4 = sf.parse(str4);      long ld3 = sDt3.getTime() /1000;      long ld4 = sDt4.getTime() /1000;     System.out.println(ld3);      System.out.println(ld4);      System.out.println(ld4-ld3);}
```

The output is:\
-1325491905-1325491552353\
Why is ld4-ld3 not 1 (as I would expect from the one-second [difference](https://www.mindstick.com/articles/157114/good-news-or-bad-news-and-the-difference-is) in the times), but 353?\
If I change the dates to times one second later:\
[String](https://www.mindstick.com/articles/1527/string-split-in-c-sharp) str3 = "1927-12-31 23:54:08"; String str4 = "1927-12-31 23:54:09";\
Java [version](https://www.mindstick.com/articles/12845/things-to-remember-while-migrating-odoo-to-a-better-version):\
java version "1.6.0_22"Java(TM) SE [Runtime](https://www.mindstick.com/articles/52/creating-timer-at-runtime-in-c-sharp-dot-net) [Environment](https://yourviews.mindstick.com/view/308/need-to-create-a-supportive-work-environment-for-women) (build 1.6.0_22-b04)[Dynamic](https://www.mindstick.com/blog/11080/features-of-java-dynamic-complied-and-interpreted) Code [Evolution](https://www.mindstick.com/articles/12901/the-evolution-of-hdmi-cables-over-the-years) Client VM (build 0.2-b02-[internal](https://www.mindstick.com/interview/773/describe-the-accessibility-modifier-protected-internal), 19.0-b04-internal, mixed mode)Timezone(TimeZone.getDefault()):\

```
sun.util.calendar.ZoneInfo[id="Asia/Shanghai",offset=28800000,dstSavings=0,useDaylight=false,transitions=19,lastRule=null]Locale(Locale.getDefault()): zh_CN
```

## Replies

### Reply by Anonymous User

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.\
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.\
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).\

```
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.


---

Original Source: https://www.mindstick.com/forum/23176/why-is-subtracting-these-two-times-in-1927-giving-a-strange-result

Copyright © MindStick Software Pvt. Ltd. This Markdown version is provided for developers, AI systems, and offline reading.