length of System.currentTimeMillis

Question

Does System.currentTimeMillis always returns a fixed length of value. In my windows Core2, it return a 13 digit long value.

From its API:

Returns the current time in milliseconds. Note that while the unit of time of the return value is a millisecond, the granularity of the value depends on the underlying operating system and may be larger. For example, many operating systems measure time in units of tens of milliseconds.

Quamash

Asking how many digits it'll contain strikes me as a deeply flawed question. The value is in milliseconds since the epoch. You can work out the number of digits as a function of the current time, but why?! – Overmatch

Set your time to be 1970 and it will much shorter. – Bolshevist

System.currentTimeMillis() returns a Java long. It will always be exactly 64 bits long and will typically have a number of leading zeroes. – Kurtzig

Answer 1

System.currentTimeMillis() returns the number of milliseconds since epoch, i.e. since midnight UTC on the 1st January 1970.

You can check when the the number of milliseconds since epoch was 13 decimal digits for the first time. This happened on

Sep 9 2001 at 01:46:40.000 UTC (1'000'000'000'000 ms since epoch)

You can also check when the number of milliseconds since epoch is going to be 13 decimal digits for the last time. This is going to happen on

Nov 20 2286 at 17:46:39.999 UTC (9'999'999'999'999 ms since epoch)

Thus between these two dates, the function will always return 13 decimal digit value assuming the machine has the current time set correctly.

So you're safe with the assumption that the return value is 13 decimal digits for more than the next two centuries.

Ostwald

I wonder how many developers out there have written code to handle 14+ digit epochs.. – Heart

@Heart For storing epoch in milliseconds to be precise. – Spec

@Heart I have seen quite a lot of code using System.currentTimeMillis() through my carrier, and I can’t remember any that had restrictions on the number of digits in the decimal representation of the result (not that I don’t see your point). – Kurtzig

@Heart just saw a 17 digit epoch storage in cassandra. Totally unrelated but 14+ made sense to me to convert safely convert to seconds since epoch and from there to human format. – Junejuneau

Answer 2

It returns a 63-digit binary number (it's actually a 64-bit signed number which is always positive, so the top bit is never set). Many of the leading digits will be zero. When you convert it to decimal, any leading zeroes are usually discarded. So, the number of decimal digits will vary.

Garceau

it's signed so that dates before 1970 can be stored – Neurologist

It's signed because longs in Java are signed. But if the designers had had the choice between signed and unsigned, signed would have been a good choice, for exactly that reason. – Garceau

Yes, that's true. I was actually commenting on the ...which is always positive part of the post, noting that that's not actually the case – Neurologist

The number returned from System.currentTimeMillis() is always positive, because it is impossible to invoke it before 1970 (or, indeed, 1996). Unless you have a time machine, or do something silly with your system clock. But yes, more generally, you're quite right that times can be negative. – Garceau

Answer 3

The most voted answer (i.e. the epoch milliseconds for any date ranging from 2001-09-09T01:46:40 UTC to 2286-11-20T17:46:39.999 UTC will have 13-digits) is spot-on. This is a supplement to that answer for anyone interested to know how one may arrive at those figures.

Usually, I write the solution using the modern date-time API first but in this case, I will reverse the pattern because java.time, the modern date-time API was released in Mar-2014 (2 years after the most voted answer was posted.

Using the legacy date-time API:

import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.Locale;
import java.util.TimeZone;

public class Main {
    public static void main(String[] args) {
        SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSSXXX", Locale.ENGLISH);
        sdf.setTimeZone(TimeZone.getTimeZone("Etc/UTC"));
        System.out.println(sdf.format(new Date(1000000000000L))); // 2001-09-09T01:46:40.000Z
        System.out.println(sdf.format(new Date(9999999999999L))); // 2286-11-20T17:46:39.999Z
    }
}

Using java.time, the modern date-time API:

import java.time.Instant;

public class Main {
    public static void main(String[] args) {
        System.out.println(Instant.ofEpochMilli(1000000000000L)); // 2001-09-09T01:46:40Z
        System.out.println(Instant.ofEpochMilli(9999999999999L)); // 2286-11-20T17:46:39.999Z
    }
}

The Z in the output is the timezone designator for 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 java.time, 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.}

Crescent