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.

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

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

Comments

[NPE]

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?!

[Vishy]

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

[Ole V.V.]

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

[Matt]

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

[Tom Anderson]

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.

[Matt]

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

[Tom Anderson]

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.

[ryanbwork]

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

[shriyog]

@ryanbwork For storing epoch in milliseconds to be precise.

[Ole V.V.]

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

[Mudit Singal]

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