System.Currenttimemillis() VS. New Date() VS. Calendar.Getinstance().Gettime()

System.currentTimeMillis() vs. new Date() vs. Calendar.getInstance().getTime()

System.currentTimeMillis() is obviously the most efficient since it does not even create an object, but new Date() is really just a thin wrapper about a long, so it is not far behind. Calendar, on the other hand, is relatively slow and very complex, since it has to deal with the considerably complexity and all the oddities that are inherent to dates and times (leap years, daylight savings, timezones, etc.).

It's generally a good idea to deal only with long timestamps or Date objects within your application, and only use Calendar when you actually need to perform date/time calculations, or to format dates for displaying them to the user. If you have to do a lot of this, using Joda Time is probably a good idea, for the cleaner interface and better performance.

Difference between System.currentTimeMillis() and Date getTime()?

No difference, except for the very slight lag caused by allocating a Date object.

From the javadoc the the default constructor of Date:

Allocates a Date object and initializes it so that it represents the time at which it was allocated, measured to the nearest millisecond.

A Date is just a thin wrapper around the epoch milliseconds, without any concept of timezones. Only when rendered to a String is timezone considered, but that is handled by the Locale class.

calendar.gettimeinmillis vs system.currenttimemillis

calendar.getTimeInMillis() will return time set on particular calendar object in millisecond. Let's say total milliseconds spend from midnight, January 1, 1970 UTC to time set on calendar object.

While System.currentTimeMillis() will return current time on your device in millisecond. In other word, total milliseconds spend from midnight, January 1, 1970 UTC until now.

currentTimeMillis vs Calendar

Calendar is always bad practice.

Java has 3 to 4 APIs for time. In order of introduction:

• System.currentTimeMillis()
• (together with the above): java.util.Date and sometime later, java.sql.Timestamp and Date. This is very bad API; at this point, almost all the methods in these are deprecated because they are misleading or straight up do not do what they suggest they do, and are in any case gigantic misnomers. j.u.Date represents an instant in time, not readily representable in human terms. Dates are fundamentally human concepts.
• Calendar. An attempt to fix the problem. Actually made it worse: The API is misleading and surprising (.set(MONTH, 1) will set the month to.. Februari!), and is entirely non-idiomatic, using .set/.get with an extra parameter with a 'field' concept, and having mutable types). The actual representational power of this API is still limited.
• JSR310, a.k.a. java.time. THIS is the good one. This has few surprises, is complex where time ends up being actually complex, the types are properly named, going so far as having both j.t.Instant and j.t.ZonedDateTime, and you can express virtually anything date-related.

I'd say using either j.u.Date or Calendar is strongly dis-recommended. If all you're doing is measuring instants in time, feel free to stick with System.currentTimeMillis() - but if ever you need to print that in human form (such as: "On 2020-07-20 at 16:34, this happened"), switch to java.time instead. If you prefer, feel free to ditch currentTimeMillis and use j.t.Instant for those purposes instead - your preference.

Accuracy of System.currentTimeMillis(), new Date().getTime(), and Calendar.getInstance().getTimeInMillis()?

If you want to refer to a specific point in time, you can definitely rely on System.currentTimeInMillis(). The three methods you describe will mark the time the same way, the difference is just what kind of object it is wrapped in. Use the variant that you need in your program.

If you want to measure the difference between two points in time during a program run, use
System.nanoTime() instead.

To get the time difference between two points in time in two separate program runs you will have to rely on external time sources if you are afraid that the user might play around with the system clock. For example, you can take a look at Java SNTP Client.

Java current time different values in api

All the functions that you used in your example return the same value (if launched in the same millisecond) none of them is more accurate.

Once of them is not creating any object, so if you need only to know the current milliseconds since 1/1/1970 use

System.currentTimeMillis()

Instead if you need to have also the equivalent object to store that value or to make additional operations use the object that you need.

For example if you need to pass this value to a function accepting a java.util.Date use java.util.Date (and so on).

Is this any different from just returning new System.currentTimeMillis()?

They are all much the same except for performance.

System.currentTimeMillis() is a system call so it takes around 0.1 to 0.3 micro-seconds (depending on your OS)

new Date() also creates an object, which takes only about 0.1 to 0.3 micro-seconds more but creates a little garbage.

Calendar.getInstance() creates an expensive set of objects and takes about 33 micro-seconds more.

static Date from = new Date(System.currentTimeMillis()), to = new Date(System.currentTimeMillis()) not Working

Use Calendar.

Date currentDate = Calendar.getInstance().getTime();

In Java 8:

LocalDateTime now = LocalDateTime.now();

---

Related Topics