I had the same issue. I get a date as a String, for example: '2016-08-25T00:00:00', but I need to have the Date object with correct time. To convert String into object, I use getTimezoneOffset:

var date = new Date('2016-08-25T00:00:00')
var userTimezoneOffset = date.getTimezoneOffset() * 60000;
new Date(date.getTime() + userTimezoneOffset);

getTimezoneOffset() will return ether negative or positive value. This must be subtracted to work in every location in world.

Try this:

function dateToEpoch(thedate) {
    var time = thedate.getTime();
    return time - (time % 86400000);
}

or this:

function dateToEpoch2(thedate) {
   return thedate.setHours(0,0,0,0);
}

Example : http://jsfiddle.net/chns490n/1/

Reference: (Number) Date.prototype.setHours(hour, min, sec, millisec)

Not possible if you only have the 2 datetimes like that. Maybe you have more info on the api data that you receive which you can use to figure out the correct timezone of each datetime

I'm still learning JavaScript, and the only way that I've found which works for me to compare two dates without the time is to use the setHours method of the Date object and set the hours, minutes, seconds and milliseconds to zero. Then compare the two dates.

For example,

date1 = new Date()
date2 = new Date(2011,8,20)

date2 will be set with hours, minutes, seconds and milliseconds to zero, but date1 will have them set to the time that date1 was created. To get rid of the hours, minutes, seconds and milliseconds on date1 do the following:

date1.setHours(0,0,0,0)

Now you can compare the two dates as DATES only without worrying about time elements.

Had the same issue, our DB and servers are set to UTC but in browser they're set to user timezone, which JS always assumes. To ensure JS knows what timezone the time you're providing is in, append it to the end of your timestamp. For example: new Date(myTimestamp + " UTC"). Yep, looks horrific but is a valid and recommended solution apparently. Welcome to JavaScript! Also be sure to check Safari support as the wah Safari handles dates is very messed up.

Background

JavaScript's Date object tracks time in UTC internally, but typically accepts input and produces output in the local time of the computer it's running on. It has very few facilities for working with time in other time zones.

The internal representation of a Date object is a single number - namely timestamp - representing the number of milliseconds that have elapsed since 1970-01-01 00:00:00 UTC, without regard to leap seconds.

There is no time zone or string format stored in the Date object itself.

When various functions of the Date object are used, the computer's local time zone is applied to the internal representation. If the function produces a string, then the computer's locale information may be taken into consideration to determine how to produce that string. The details vary per function, and some are implementation-specific.

The only operations the Date object can do with non-local time zones are:

• It can parse a string containing a numeric UTC offset from any time zone. It uses this to adjust the value being parsed, and stores the UTC equivalent. The original local time and offset are not retained in the resulting Date object. For example:

    var d = new Date("2020-04-13T00:00:00.000+08:00");
    d.toISOString()  //=> "2020-04-12T16:00:00.000Z"
    d.valueOf()      //=> 1586707200000  (this is what is actually stored in the object)
  

• In environments that have implemented the ECMASCript Internationalization API (aka "Intl"), a Date object can produce a locale-specific string adjusted to a given time zone identifier. This is accomplished via the timeZone option to toLocaleString and its variations. Most implementations will support IANA time zone identifiers, such as 'America/New_York'. For example:

    var d = new Date("2020-04-13T00:00:00.000+08:00");
    d.toLocaleString('en-US', { timeZone: 'America/New_York' })
    //=> "4/12/2020, 12:00:00 PM"
    // (midnight in China on April 13th is noon in New York on April 12th)
  

  Most modern environments support the full set of IANA time zone identifiers (see the compatibility table here). However, keep in mind that the only identifier required to be supported by Intl is 'UTC', thus you should check carefully if you need to support older browsers or atypical environments (for example, lightweight IoT devices).

Libraries

There are several libraries that can be used to work with time zones. Though they still cannot make the Date object behave any differently, they typically implement the standard IANA timezone database and provide functions for using it in JavaScript. Modern libraries use the time zone data supplied by the Intl API, but older libraries typically have overhead, especially if you are running in a web browser, as the database can get a bit large. Some of these libraries also allow you to selectively reduce the data set, either by which time zones are supported and/or by the range of dates you can work with.

Here are the libraries to consider:

Intl-based Libraries

New development should choose from one of these implementations, which rely on the Intl API for their time zone data:

• Luxon (successor of Moment.js)
• date-fns-tz (extension for date-fns)
• Day.js (when using its Timezone plugin)

Non-Intl Libraries

These libraries are maintained, but carry the burden of packaging their own time zone data, which can be quite large.

• js-joda/timezone (extension for js-joda)
• moment-timezone* (extension for Moment.js)
• date-fns-timezone (extension for older 1.x of date-fns)
• BigEasy/TimeZone
• tz.js

* While Moment and Moment-Timezone were previously recommended, the Moment team now prefers users chose Luxon for new development.

Discontinued Libraries

These libraries have been officially discontinued and should no longer be used.

• WallTime-js
• TimeZoneJS

Future Proposals

The TC39 Temporal Proposal aims to provide a new set of standard objects for working with dates and times in the JavaScript language itself. This will include support for a time zone aware object.

Common Errors

There are several approaches that are often tried, which are in error and should usually be avoided.

Re-Parsing

new Date(new Date().toLocaleString('en', {timeZone: 'America/New_York'}))

The above approach correctly uses the Intl API to create a string in a specific time zone, but then it incorrectly passes that string back into the Date constructor. In this case, parsing will be implementation-specific, and may fail entirely. If successful, it is likely that the resulting Date object now represents the wrong instant in time, as the computer's local time zone would be applied during parsing.

Epoch Shifting

var d = new Date();
d.setTime(d.getTime() + someOffset * 60000);

The above approach attempts to manipulate the Date object's time zone by shifting the Unix timestamp by some other time zone offset. However, since the Date object only tracks time in UTC, it actually just makes the Date object represent a different point in time.

The same approach is sometimes used directly on the constructor, and is also invalid.

Epoch Shifting is sometimes used internally in date libraries as a shortcut to avoid writing calendar arithmetic. When doing so, any access to non-UTC properties must be avoided. For example, once shifted, a call to getUTCHours would be acceptable, but a call to getHours would be invalid because it uses the local time zone.

It is called "epoch shifting", because when used correctly, the Unix Epoch (1970-01-01T00:00:00.000Z) is now no longer correlated to a timestamp of 0 but has shifted to a different timestamp by the amount of the offset.

If you're not authoring a date library, you should not be epoch shifting.

For more details about epoch shifting, watch this video clip from Greg Miller at CppCon 2015. The video is about time_t in C++, but the explanation and problems are identical. (For JavaScript folks, every time you hear Greg mention time_t, just think "Date object".)

Trying to make a "UTC Date"

var d = new Date();
var utcDate = new Date(Date.UTC(d.getUTCFullYear(), d.getUTCMonth(), d.getUTCDate(), d.getUTCHours(), d.getUTCMinutes(), d.getUTCSeconds(), d.getUTCMilliseconds()));

In this example, both d and utcDate are identical. The work to construct utcDate was redundant, because d is already in terms of UTC. Examining the output of toISOString, getTime, or valueOf functions will show identical values for both variables.

A similar approach seen is:

var d = new Date();
var utcDate = new Date(d.getUTCFullYear(), d.getUTCMonth(), d.getUTCDate(), d.getUTCHours(), d.getUTCMinutes(), d.getUTCSeconds(), d.getUTCMilliseconds());

This is approach passes UTC values into the Date constructor where local time values are expected. The resulting Date object now represents a completely different point in time. It is essentially the same result as epoch shifting described earlier, and thus should be avoided.

The correct way to get a UTC-based Date object is simply new Date(). If you need a string representation that is in UTC, then use new Date().toISOString().

Unfortunately, there seems to be no "simple" or built-in way how to get the actual time in different timezone. So I solved it by using powershell :) Here is the method I'm using...// Get actual date in defined format and Time Zone function GetSetActualDate(dateFormat, timeZoneString) {  var oShell = getActiveXObject("WScript.Shell"); // Or oShell = WshShell  var oExec = oShell.Exec("powershell -command [System.TimeZoneInfo]::ConvertTime( (Get-Date), (Get-TimeZone -Id \\\"" + timeZoneString + "\\\")).ToString(\\\"" + dateFormat + "\\\")");  oExec.StdIn.Close(); // Close standard input before reading output  // Get PowerShell output  var strOutput = oExec.StdOut.ReadAll();  // Trim leading and trailing empty lines  strOutput = aqString.Trim(strOutput, aqString.stAll);  return strOutput;}And this is how it looks in keyword test:I still believe the TC should directly support INTL library (now unsupported in JavaScript) and dynamic loading of external libraries is a must in a modern TA tool! I will make a feature request for both issues. But of course, I'm not naive to think that they will be fixed anytime soon :D Have a nice day.

You could use Intl.DateTimeFormat.

let options = {
    timeZone: 'Europe/London',
    year: 'numeric',
    month: 'numeric',
    day: 'numeric',
    hour: 'numeric',
    minute: 'numeric',
    second: 'numeric',
  },
  formatter = new Intl.DateTimeFormat([], options);

console.log(formatter.format(new Date()));

Alternatively, if you're formatting just once instead of bulk use Date.prototype.toLocaleDateString().

(new Date()).toLocaleString([], options)

Unfortunately browsers are not required to understand timezones other than UTC, so try these blocks and figure out an alternative in case it fails, for example fetch the timezone offset from a server.

Using an offset to calculate Timezone is a wrong approach, and you will always encounter problems. Time zones and daylight saving rules may change on several occasions during a year, and It's difficult to keep up with changes.

To get the system's IANA timezone in JavaScript, you should use

console.log(Intl.DateTimeFormat().resolvedOptions().timeZone)

As of April 2023, this works in 95.42% of the browsers used globally.

Old compatibility information

ecma-402/1.0 says that timeZone may be undefined if not provided to constructor. However, future draft (3.0) fixed that issue by changing to system default timezone.

In this version of the ECMAScript Internationalization API, the timeZone property will remain undefined if no timeZone property was provided in the options object provided to the Intl.DateTimeFormat constructor. However, applications should not rely on this, as future versions may return a String value identifying the host environment’s current time zone instead.

in ecma-402/3.0 which is still in a draft it changed to

In this version of the ECMAScript 2015 Internationalization API, the timeZone property will be the name of the default time zone if no timeZone property was provided in the options object provided to the Intl.DateTimeFormat constructor. The previous version left the timeZone property undefined in this case.