Equivalent of new Date().getTime() in Java 8

Question

Before Java 8 I was using in code new Date().getTime() to obtain current timestamp as number. Can I assume that Instant.now().toEpochMilli() is safe equivalent to the legacy way? Does it have exactly the same behavior and similar performance characteristics? Are there any better alternatives?

I want to use the Java 8 way in ecosystem where all surrounding components still use new Date().getTime(), so produced results must be consistent.

Novick

System.currentTimeMillis() it's old but probably the same that the other classes are using – Roughshod

"Before Java 8 I was using in code" You could have simply been using System.currentTimeMillis(). – Seif

Side note: you can do Instant instantFromDate = new Date().toInstant() too ;-) – Gallery

Answer 1

All of Instant.now().toEpochMilli(), new Date().getTime() and System.currentTimeMillis() will give you the number of milliseconds since epoch.

From CPU power and memory allocation point of view, you should use System.currentTimeMillis() because it's a native method that delegates the task to the underlying operating system (this calculation usually is very optimized and doesn't require garbage collection etc).

Arin

Answer 2

Two options

1. Instant.now().toEpochMilli(), as you said
2. System.currentTimeMillis() as Andy Turner and Marteng said

The choice between the two a matter of taste. Instant is the modern replacement for Date and to many the natural choice. Use it if you want to give a modern impression. System.currentTimeMillis() is as old as Date. While Date is decidedly poorly designed and should be avoided always, I am not aware of any design problems with System.currentTimeMillis().

Even more modern: keep the Instant

Using a long to represent a point in time is very low-level and hard to debug because we don’t naturally assign any meaning to the number. If you can, instead of keeping a number, keep an Instant. It also gives you an even finer resolution than milliseconds (since Java 9 Instant.now() has a precision of microseconds on many platforms).

Safe and performant?

Can I assume that Instant.now().toEpochMilli() is safe equivalent to the legacy way? Does it have exactly the same behavior and similar performance characteristics?

Yes, it is safe and equivalent and has similar performance characteristics.

Only under all circumstances avoid Date and Calendar. They are poorly designed and long outdated and have modern replacements.

Berky

In my case I cannot keep an Instant as I need to serialize data into human readable JSON format. Other way would be to represent current time as ISO timestamp, however we chose long for simplicity. – Novick

Thanks for explaining. Had it been me, I would have picked ISO 8601 (like 2019-09-11T07:23:18.485924Z) for human readability and simplicity of debugging, but you have to make your choice for your situation. – Berky

We mainly compare timestamps (it's not relevant when an event occurred, but which was first), so number and comparing with standard operators like < won. – Novick

"long to represent a point in time is very low-level and hard to debug". Not if you know it is supposed to be a time, and I would argue often you do. Here (where there are two wrapper choices available) it is the canonical representation. – Filiano