29

Well, you might think that this question has already been asked, but I think it has not. The solutions I've read about all had this "jigsaw puzzle" technique (like getUTCMonth() + getUTCMinutes + ...). But as I only want to compare the elapsed seconds between two UTC (!) dates, this does not apply.

As everybody knows, you can get the current (non-UTC) date by:

var d = new Date();
var t_millis = d.getTime();

But this is NOT what I want. I'd like to have the current system date in UTC and in milliseconds, so not mess about with strings at all. AFAIK the variable t_millis will contain the millisecond value of the current timestamp in GMT, not UTC. (Since d is in GMT as well. Unless getTime() does a sort of implicit time zone conversion, i. e. adding the offset BEFORE giving out the milliseconds, but I've never read about that anywhere)

So is there really no other way than adding the offset to the time value? I'm desperately missing a function like getUTCTimeMillis() known from other languages.

Alexander Abakumov
  • 13,617
  • 16
  • 88
  • 129
syntaxerror
  • 661
  • 2
  • 6
  • 24
  • 2
    I don't understand. UTC *is* GMT, to all intents and purposes. – Andrew Leach Jun 01 '12 at 21:10
  • Yes UTC is GMT...I should have said "local time" instead. My bad. When I mean "GMT" I usually mean the opposite of UTC, i. e. local time shown by GMT+/-offset, whilst I consider UTC = constant. – syntaxerror Jun 03 '12 at 16:58

5 Answers5

61

This is an old question but for the sake of the new visitors here is THE CORRECT ANSWER:

Date.now();

It returns the number of milliseconds elapsed since 1 January 1970 00:00:00 UTC

advncd
  • 3,787
  • 1
  • 25
  • 31
21

The millisecond value of the time-of-day is going to be the same regardless of your time zone. That is, there are no time zones on planet Earth that differ from one another by a number of milliseconds greater than zero. (They may differ by an integer number of hours or even minutes, but not seconds or milliseconds.)

That said, the value you get back from getTime() is a UTC-relative timestamp. If two web browsers at widely different spots on the globe create a Date object at the same time, they'll both get the same value from .getTime() (assuming the clocks are synchronized, which is of course highly unlikely).

Here: 1338585185539 That's a timestamp I just got from my browser. I'm in Austin, TX, and now it's 4:13 in the afternoon (so that timestamp will be from slightly before that). Plug it into a Date instance on your machine and see what it says.

(edit — for posterity's sake, that timestamp is from 1 June 2012.)

Pointy
  • 405,095
  • 59
  • 585
  • 614
  • Thanks! Yes I'm getting it now. So if we are sure that the Date object is definitely a GMT value, we could logically conclude that getTime() must stealthily perform a GMT-to-UTC conversion _before_ calculating the milliseconds. – syntaxerror Jun 03 '12 at 16:50
  • Sorry but i don't agree with this. Indeed the time which passed since 1970 in one timezone is identical to the time in any other timezone, but UTC is something else. Why would you have so many functions parallel to the standard Date functions that have UTC in their name? Here is an explanation why UTC is almost the same as GMT but not quite: – Sandman Aug 21 '13 at 18:32
  • @Teo huh? The UTC Date functions are there because the non-UTC APIs all report time/date relative to the local timezone. – Pointy Aug 21 '13 at 18:35
  • 1
    Sorry about my incomplete post (i was trying to link to a wikipedia paragraph). Yes but there are 2 things i don't really agree with, hopefully i'm not misunderstanding: that getTime() is a UTC-relative timestamp and that a GMT-to-UTC conversion (or any kind of conversion) should be implicitly performed before calculating getTime() – Sandman Aug 21 '13 at 18:43
  • 1
    getTime() is a timezone relative, not UTC relative value (this is why it's the same everywhere), and getTime() does no conversion whatsoever, right? If you want any kind of synchronization across timezones (which is why i suspect this question was asked in the first place) you would need the common reference that is UTC. If you only want to measure elapsed time in your local timezone then it doesn't really matter, you can use getTime() – Sandman Aug 21 '13 at 18:50
  • @Teo `getTime()` returns a UTC timestamp value. At a given point in time, the timestamp value is the same regardless of the time zone. The timestamp is always a count of milliseconds since a particular UTC point in time. – Pointy Aug 21 '13 at 18:52
  • So then you're essentially saying that getTime() returns the milliseconds since Jan 1, 1970 UTC(GMT)? While i'm saying that getTime() returns the milliseconds since Jan 1, 1970 MY TIMEZONE :) The way i see it it can't return the time since Jan 1, 1970 UTC because then in Cairo getTime() would be 3600000 milliseconds more than in Paris if called in the exact same moment in both cities. However it's not, it's the same :) – Sandman Aug 21 '13 at 19:03
  • @Teo yes, `getTime()` returns the milliseconds since midnight (UTC), 1 Jan 1970. [Here is the documentation.](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/getTime?redirectlocale=en-US&redirectslug=JavaScript%2FReference%2FGlobal_Objects%2FDate%2FgetTime) The result of calling `.getTime()` is the same in Cairo and in Paris, at any given point in time. – Pointy Aug 21 '13 at 19:06
  • Yes, you are right! Sorry for wasting your time, but in my defense i learned something today :) I was thinking of UTC in terms of timezones which i really shouldn't. – Sandman Aug 21 '13 at 19:12
  • milliseconds part will be the same (e.g. 615ms in Greenwich will be 615ms in Istanbul) but OP asks, "current date in milliseconds". The full date in milliseconds will be different from the local time. `1429830821615 !== 1429841621615`. (notice the last 3 digits and digits before those) – Onur Yıldırım Apr 23 '15 at 23:19
  • @OnurYıldırım I think you should read the rest of my answer. The point is that the `.getTime()` return value is **always** a UTC timestamp. – Pointy Apr 24 '15 at 01:37
7

how about:

var now = new Date();
var utc_now = new Date(now.getUTCFullYear(), now.getUTCMonth(), now.getUTCDate(),  now.getUTCHours(), now.getUTCMinutes(), now.getUTCSeconds(), now.getUTCMilliseconds());
console.log('UTC: ' + utc_now) // correct UTC time but wrong timezone!
console.log('UTC (in ms): ' + utc_now.getTime())
kirpit
  • 4,419
  • 1
  • 30
  • 32
  • Just an FYI on that you can leave out the UTC portion. (IE now.getFullYear() instead of now.getUTCFullYear() ). – Ryan Q Sep 30 '13 at 21:46
  • 1
    @RyanQ if he does what would be the difference between `now` and `utc_now`? That's the whole point here. – Odys Apr 11 '14 at 22:09
6

I have used this function to solve the problem.

function getUTCNow()
{
    var now = new Date();
    var time = now.getTime();
    var offset = now.getTimezoneOffset();
    offset = offset * 60000;
    return time - offset;
}
  • The getTime function returns the number of milliseconds elapsed since 1 January 1970 00:00:00 in the client timezone.
  • getTimezoneOffset return offset in minutes between Client timezone and UTC.
  • offset = offset * 60000; this operation transform minutes in miliseconds.
  • subtracting the offset get the number of milliseconds elapsed since 1 January 1970 00:00:00 UTC.
Blacknet
  • 119
  • 1
  • 7
  • The getTime function returns the number of milliseconds elapsed since 1 January 1970 00:00:00 in the client timezone. getTimezoneOffset return offset in minutes between Client timezone and UTC. offset = offset * 60000; this operation transform minutes in miliseconds. subtracting the offset get the number of milliseconds elapsed since 1 January 1970 00:00:00 UTC. – Blacknet Dec 11 '15 at 07:32
  • Here's a one-liner for current browsers: `Date.nowUTC=()=>(d=>d.getTime()-(d.getTimezoneOffset()*6e4))(new Date())` – Mr. Polywhirl Feb 14 '17 at 16:40
  • 2
    I don't think this is correct. According to [MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/getTime): `getTime() always uses UTC for time representation. For example, a client browser in one timezone, getTime() will be the same as a client browser in any other timezone.`. Additionally, they say that the return value is `A number representing the milliseconds elapsed between 1 January 1970 00:00:00 UTC and the given date.` **Not** the number of milliseconds in the client timezone. – Noah Allen Aug 18 '18 at 19:20
  • 1
    @noa I thought so too, but if you 1) var a = new Date(); 2) a.setHours(0,0,0,0); 3) a.getTime(), - it returns timestamp that is not the original date, but a modified date. I think they need to fix the documentation – Dmitry Dec 30 '20 at 16:36
3

To get the timestamp from a date in UTC, you need to take in consideration the timezone and daylight savings for that date. For example, a date in January or in July could mean 1 hour difference.

The option below does just that.

Date.prototype.getUTCTime = function () {
    return this.getTime() - (this.getTimezoneOffset() * 60000);
};

It can be used as in:

var date = new Date();
var timestamp = date.getUTCTime();
Darlesson
  • 5,742
  • 2
  • 21
  • 26