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.

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**?! — NPE, Feb 05 '12 at 12:31
`System.currentTimeMillis()` returns a Java `long`. It will always be exactly 64 bits long and will typically have a number of leading zeroes. — Ole V.V., May 22 '21 at 17:17

Adam Zalcman · Answer 1 · 2012-02-05T13:18:26.807

54

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.

edited Feb 05 '12 at 13:18

answered Feb 05 '12 at 12:37

Adam Zalcman

26,643
4
71
92

10

I wonder how many developers out there have written code to handle 14+ digit epochs.. – ryanbwork Sep 10 '15 at 23:18
@ryanbwork For storing epoch in **milliseconds** to be precise. – shriyog Oct 12 '18 at 14:23
@ryanbwork 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). – Ole V.V. May 23 '21 at 05:56
@ryanbwork 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. – Mudit Singal Apr 02 '22 at 19:00

score 2 · Answer 2 · answered Feb 05 '12 at 12:35

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.

answered Feb 05 '12 at 12:35

Tom Anderson

46,189
17
92
133

it's signed so that dates before 1970 can be stored – Matt Feb 05 '12 at 13:45
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. – Tom Anderson Feb 05 '12 at 15:33
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 – Matt Feb 05 '12 at 16:06
2

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. – Tom Anderson Feb 05 '12 at 21:32

score 0 · Answer 3 · answered May 22 '21 at 16:32

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

length of System.currentTimeMillis

3 Answers3

Linked