Take the 2-minute tour ×

In Java, what are the performance and resource implications of using



new Date()



As I understand it, System.currentTimeMillis() is the most efficient. However, in most applications, that long value would need to be converted to a Date or some similar object to do anything meaningful to humans.

share|improve this question

8 Answers 8

up vote 93 down vote accepted

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.

share|improve this answer

If you're USING a date then I strongly advise that you use jodatime, http://joda-time.sourceforge.net/. Using System.currentTimeMillis() for fields that are dates sounds like a very bad idea because you'll end up with a lot of useless code.

Both date and calendar are seriously borked, and Calendar is definitely the worst performer of them all.

I'd advise you to use System.currentTimeMillis() when you are actually operating with milliseconds, for instance like this

 long start = System.currentTimeMillis();
    .... do something ...
 long elapsed = System.currentTimeMillis() -start;
share|improve this answer
I wanted to comment on this because your example is exactly one of the things you should NOT use System.currentTimeMillis() for; it is not a monotonic clock source, so you cannot reliably calculate elapsed time with it. If the system clock is changed while the code you are timing is executing, you will get weird (e.g. negative) results. In stead use System.nanoTime(), which is monotonic if the underlying system supports such a clock source (see bugs.java.com/bugdatabase/view_bug.do?bug_id=6458294 ) –  rem Apr 9 at 14:53

Looking at the JDK, innermost constructor for Calendar.getInstance() has this:

public GregorianCalendar(TimeZone zone, Locale aLocale) {
    super(zone, aLocale);
    gdate = (BaseCalendar.Date) gcal.newCalendarDate(zone);

so it already automatically does what you suggest. Date's constructor default constructor holds this:

public Date() {

So there really isn't need to get system time specifically unless you want to do some math with it before creating your Calendar/Date object with it. Also I do have to recommend joda-time to use as replacement for Java's own calendar/date classes if your purpose is to work with date calculations a lot.

share|improve this answer

Depending on your application, you may want to consider using System.nanoTime() instead.

share|improve this answer
Why, his question was about resources and performance, nanoTime() uses more resources –  WolfmanDragon Dec 15 '08 at 22:17
I mentioned it because it's an option that no one else suggested. The poster did not specify a platform. SDN bug 6876279 suggests that currentTimeMillis() and nanoTime() take about the same in some JDK versions. The poster also did not specify their accuracy needs, for which the original list may be inadequate. –  MykennaC May 28 '10 at 18:14
Late as this may be, all the examples in the question have an absolute notion of what time it is eg. 1,348,770,313,071 millis since the start of the Unix epoch. The time that nanoTime returns is relative (usually to the start of the program) and would be nonsense if you tried to turn it into a date. –  Dunes Sep 27 '12 at 18:28
yes but you could store currentTimeilli and nano in some static code on program start, then use those as offsets to get an accurate nano from milli using a double var = currentTimeStart - nanoTimeStart + nanoTimeNow –  tgkprog Dec 18 '13 at 13:47

I prefer using the value returned by System.currentTimeMillis() for all kinds of calculations and only use Calendar or Date if I need to really display a value that is read by humans. This will also prevent 99% of your daylight-saving-time bugs. :)

share|improve this answer

On my machine I tried check it. My result:

Calendar.getInstance().getTime() (*1000000 times) = 402ms
new Date().getTime(); (*1000000 times) = 18ms
System.currentTimeMillis() (*1000000 times) = 16ms

Don't forget about GC (if you use Calendar.getInstance() or new Date())

share|improve this answer
wonder if there will be any difference if many threads call the same in between other processing –  tgkprog Dec 18 '13 at 13:32

I tried this:

        long now = System.currentTimeMillis();
            new Date().getTime();
        long result = System.currentTimeMillis() - now;

        System.out.println("Date(): " + result);

        now = System.currentTimeMillis();
        result = System.currentTimeMillis() - now;

        System.out.println("currentTimeMillis(): " + result);

And result was:

Date(): 199

currentTimeMillis(): 3

share|improve this answer
This is a micro benchmark and you should be careful to trust the results you get. Have a look at stackoverflow.com/questions/504103/…. –  Axel Jan 24 at 17:32

System.currentTimeMillis() is obviously the fastest because it's only one method call and no garbage collector is required.

share|improve this answer
Your answer holds no value since it is just a subset of the previously approved answer. You should try not to answer in this manner, especially not considering it is a very old question with a already existing quality answer. –  Nicklas Gnejs Eriksson Jan 24 at 17:38

Your Answer


