155
var timeInMs = Date.now();

per MDN

vs.

var timeInMs = new Date(optional).getTime();

per MDN.

Is there any difference between the two, besides the syntax and the ability to set the Date (to not the current) via optional in the second version?

Date.now() is faster - check out the jsperf

Penny Liu
  • 15,447
  • 5
  • 79
  • 98
  • 72
    for anyone who cares, Date.now() doesn’t work in Internet Explorer versions earlier than IE9. I myself don't care – guido Sep 20 '12 at 17:08
  • 11
    For what it's worth, you can add the compatibility shim mentioned in https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Date/now to make Date.now() work on IE<9, too. – jonvuri Sep 20 '12 at 17:43
  • 1
    http://jsben.ch/#/TOF9y – EscapeNetscape Oct 21 '16 at 21:36

7 Answers7

140

These things are the same (edit semantically; performance is a little better with .now()):

var t1 = Date.now();
var t2 = new Date().getTime();

However, the time value from any already-created Date instance is frozen at the time of its construction (or at whatever time/date it's been set to). That is, if you do this:

var now = new Date();

and then wait a while, a subsequent call to now.getTime() will tell the time at the point the variable was set.

Kevin Ji
  • 10,479
  • 4
  • 40
  • 63
Pointy
  • 405,095
  • 59
  • 585
  • 614
  • 1
    Do you think it would be more performant to create one date object in the beginnign of the program and then just update that date object (`dateObj.setTime(Date.now())`) or create new date objects every time you do something asynchronous that needs to access `Date` methods (such as `dateObj.getMinutes()`) ? – doubleOrt Jan 21 '18 at 19:08
  • 6
    @Taurus modern JavaScript runtimes are *extremely* good at object creation and garbage collection. Unless you're working on some sort of real-time game kernel, there's no reason at all to worry about it. Write code that looks good and isn't fragile. – Pointy Jan 21 '18 at 19:11
  • 1
    not supposed to say thanks but thanks (I hope I haven't done this more than once). – doubleOrt Jan 21 '18 at 19:27
73

They are effectively equivalent, but you should use Date.now(). It's clearer and about twice as fast.

Edit: Source: http://jsperf.com/date-now-vs-new-date

vegemite4me
  • 6,621
  • 5
  • 53
  • 79
jonvuri
  • 5,738
  • 3
  • 24
  • 32
  • 2
    Is this because `Date(optional).getTime();` has to allocate space to get a new Date object before getting the current time? – Charlie G Sep 20 '12 at 17:07
  • Probably, yes. I would expect that it has more to do with everything that the Date constructor is doing rather than the actual allocation of the object, though. – jonvuri Sep 20 '12 at 17:43
  • Yeah, I added that hasily - I meant the allocation and everything that goes along with creating an object. – Charlie G Sep 20 '12 at 17:53
  • 2
    @vegemite4me Mentioned link is broken! – cmcodes Jun 08 '22 at 12:14
  • @cmcodes Not my answer, but you can try this: https://jsbench.me/f5k9ckm6lh/1 – vegemite4me Jun 08 '22 at 21:25
  • It is important to note the absolute performance of these things in addition to the relative performance. The slowest one ran 4 million times per second for me. Which means the most important takeaway for my purposes is to take care not to do any of these hundreds of times per frame (which I would instinctively avoid already, but it's easy to lose track). But since I can avoid that, I should use whichever one is otherwise most useful. – cesoid Jul 09 '22 at 11:50
5

When you do (new Date()).getTime() you are creating a new Date object. If you do this repeatedly, it will be about 2x slower than Date.now()

The same principle should apply for Array.prototype.slice.call(arguments, 0) vs [].slice.call(arguments, 0)

Gregory Magarshak
  • 1,883
  • 2
  • 25
  • 35
3

Yes, that is correct; they are effectively equivalent when using the current time.

Brett Zamir
  • 14,034
  • 6
  • 54
  • 77
3

Sometimes it's preferable to keep some time tracking variable in a Date object format rather than as just a number of milliseconds, to have access to Date's methods without re-instantiating. In that case, Date.now() still wins over new Date() or the like, though only by about 20% on my Chrome and by a tiny amount on IE.

See my JSPERF on

timeStamp2.setTime(Date.now()); // set to current;

vs.

timeStamp1 = new Date(); // set to current;

http://jsperf.com/new-date-vs-settime

SashaK
  • 165
  • 6
0

I tried to find the extracly answer for your question. I found a page with a benchmark so clearly.

The static Date.now() method returns the number of milliseconds elapsed since January 1, 1970 00:00:00 UTC.

The getTime() method returns the number of milliseconds since the ECMAScript epoch. You can use this method to help assign a date and time to another Date object. This method is functionally equivalent to the valueOf() method.

Source: https://developer.mozilla.org/

ex:

const moonLanding = new Date('July 20, 69 20:17:40 GMT+00:00');

console.log('getTime:::', moonLanding.getTime()); // expected output: -14182940000
console.log('valueOf:::', moonLanding.valueOf()); // expected output: -14182940000
Nak
  • 251
  • 1
  • 6
-1

Date.now() is calling the static method now() of the class Date. While new Date().getTime() can be divided into two steps:

  1. new Date(): Call the constructor() method of Date class to initialize an instance of Date class.
  2. Call getTime() method of the instance we just initialize.

MDN web docs classifies Date.now() into static method of Date, and Date.prototype.getTime() into instance method.

han9912
  • 1
  • 1