Why is subtracting these two epoch-milli Times (in year 1927) giving a strange result?

Why is subtracting these two epoch-milli Times (in year 1927) giving a strange result?

Hey there! 👋 Are you ready to dive into a puzzling problem in Java? Today, we're going to investigate why subtracting two epoch-milli Times from the year 1927 is giving us a strange result. 🤔

The Context and the Code 💻

Let's start by looking at the provided code snippet:

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(ld4 - ld3);
}

This code parses two date strings, str3 and str4, and calculates the difference between their epoch-milli Times. In this specific case, the expected result would be 1 since the times are just one second apart.

The Unexpected Result 🤔

Surprisingly, when we run the code, the output is 353 instead of 1. 😲 What's going on here?

The Culprit: Timezone and Locale 🕒🌍

The root cause of this strange result lies in two factors: Timezone and Locale settings. Let's break it down:

Timezone: Asia/Shanghai 🌍

In the provided Java version, the default timezone is set to Asia/Shanghai. This information is important because when we parse the date strings, the parsing is affected by the timezone offset of +8 hours (or 28800000 milliseconds).

Locale: zh_CN 🇨🇳

The default Locale is set to zh_CN, which represents the Chinese language and culture. However, for our specific problem, the Locale itself doesn't directly contribute to the strange result. It is mainly the timezone that affects the outcome.

The Explanation 📚

To understand why ld4 - ld3 is 353 instead of 1, let's break down the process step by step:

1. sDt3.getTime() returns the number of milliseconds since January 1, 1970, 00:00:00 GMT for the date 1927-12-31 23:54:07. In this case, we have -1325497593000 milliseconds.

2. Similarly, sDt4.getTime() returns the number of milliseconds since January 1, 1970, 00:00:00 GMT for the date 1927-12-31 23:54:08. This time, we have -1325497592000 milliseconds.

3. Now, we divide both values by 1000 to convert them into seconds.

4. Due to the default timezone being Asia/Shanghai with an offset of +8 hours, the epoch-milli time is effectively shifted by 28800000 milliseconds.

5. After the division, ld3 becomes -16569 and ld4 becomes -16568, which represents the number of seconds elapsed since January 1, 1970, 00:00:00 GMT, adjusted for the timezone.

6. The difference between ld4 and ld3 is then calculated as -16568 - (-16569), which equals 1.

The Solution ✅

If you want to obtain the expected difference of 1 second, there are a few possible solutions:

1. Use a specific timezone or the GMT/UTC timezone, which will not apply any offset during parsing and calculation.

2. Adjust the code to utilize a time library like java.time in Java 8 and above, which provides more robust handling of date and time operations.

3. If the purpose is solely to obtain the difference in seconds, you can simplify the code by calculating the difference directly on the original Date objects, without dividing them by 1000. Then, the result will be in milliseconds, and you can convert it to seconds afterwards.

🎉 Your Turn to Engage! 🎉

Now that you understand why subtracting these two epoch-milli Times in the year 1927 gives a strange result, it's time for you to put your knowledge into action! 🙌

Do you have any similar experiences or insights into this problem? Let us know in the comments below! And if you found this blog post helpful, share it with your tech-savvy friends to spread the knowledge! 👯‍♀️