Why Java Unix time and Calendar calculate exact time?

Question

I heard that Unix time does not include "Leap Second". And I also heard that Java Calendar API does not include Leap second.

Since 1972, 27 seconds were added as the Leap second. And Unix time began 1970-01-01 00:00:00 (UTC).

So, I thought that there are 27 seconds difference between current UTC time and Unix time.

To clarify my thought, I did some experiment like below. 1614766198 was a Unix time at 2021-03-03 10:10:00 (UTC+0)

import java.util.Calendar;
import java.util.TimeZone;

public class CanendarTest {
    public static void main(String[] args) throws InterruptedException {

        Calendar cal = Calendar.getInstance(TimeZone.getTimeZone("UTC"));
        
        cal.setTimeInMillis(1614766198L * 1000);
        System.out.println(cal.get(Calendar.YEAR));
        System.out.println(cal.get(Calendar.MONTH));
        System.out.println(cal.get(Calendar.DAY_OF_MONTH));
        System.out.println(cal.get(Calendar.HOUR_OF_DAY));
        System.out.println(cal.get(Calendar.MINUTE));
        System.out.println(cal.get(Calendar.SECOND));
    }
}

The result of above code was

output
2021
2
3
10
9
58

Output seems like "2021-03-03 10:09:58".

So, My Question is that, Why Java Calendar API return 2 second difference from 1970-01-01 00:00:00 (UTC) not 27 second difference?

I recommend you don’t use `Calendar`. That class is poorly designed and long outdated. Instead use `Instant` from [java.time, the modern Java date and time API](https://docs.oracle.com/javase/tutorial/datetime/). — Ole V.V., Mar 06 '21 at 10:11
You are wrong, sorry. 1614766198 does equal Wednesday 3. March 2021 10:09:58 UTC. [Check yourself here.](https://www.epochconverter.com/). The Unix timestamp for 2021-03-03 10:10:00 (UTC+0) would have to end on a couple of zeros. — Ole V.V., Mar 06 '21 at 10:15
Leap seconds are meant to be ignored in the context of a calendar (years, months, days). Days are not *exactly* 24 hours long. To maintain the illusion that days are 24 hours long, every few years we slow our clocks (spinning of the earth on its axis) a second to keep in sync with the calendar (earth orbiting the sun). So both Unix time and *java.time* classes purposely ignore, or “swallow”, the leap second. (P.S. Never use the terrible `Calendar` & `Date` classes.) — Basil Bourque, Jul 02 '21 at 18:10

score 3 · Accepted Answer · answered Jul 02 '21 at 17:57

1614766198 was a Unix time at 2021-03-03 10:10:00 (UTC+0)

This is not correct. The following UNIX command

TZ=UTC date -r 1614766198

outputs

Wed  3 Mar 2021 10:09:58 UTC

java.time

The java.util Date-Time API and their formatting API, SimpleDateFormat are outdated and error-prone. It is recommended to stop using them completely and switch to the modern Date-Time API^*.

Solution using java.time, the modern Date-Time API:

import java.time.Instant;

public class Main {
    public static void main(String[] args) {
        Instant instant = Instant.ofEpochSecond(1614766198);
        System.out.println(instant);
    }
}

Output:

2021-03-03T10:09:58Z

ONLINE DEMO

An Instant represents an instantaneous point on the timeline in UTC. The Z in the output is the timezone designator for a zero-timezone offset. It stands for Zulu and specifies the Etc/UTC timezone (which has the timezone offset of +00:00 hours).

Learn more about the modern Date-Time API from Trail: Date Time.

^{* For any reason, if you have to stick to Java 6 or Java 7, you can use ThreeTen-Backport which backports most of the java.time functionality to Java 6 & 7. If you are working for an Android project and your Android API level is still not compliant with Java-8, check Java 8+ APIs available through desugaring and How to use ThreeTenABP in Android Project.}

Why Java Unix time and Calendar calculate exact time?

1 Answers1

java.time