这里有几个工作答案，但不知为何，他们中的很多人似乎让你到字符串，但不是回到一个日期对象，你开始，所以这里是我的简单的非函数采取如何在JS日期更改时区:

var TZ='Australia/Brisbane'; //Target timezone from server
var date = new Date();       //Init this to a time if you don't want current time
date=new Date(Date.parse(date.toLocaleString("en-US", {timeZone: TZ})));
//Just a clarification on what happens
// 1) First new Date() gives you a Date object at current time in the clients browser local timezone
// 2) .toLocaleString takes that time, and returns a string if time in the target timezone
// 3) Date.parse converts that new string to a Unix epoch number
// 4) new Date() converts the Unix epoch into a Date object in the new TimeZone. 
// Now I can use my usual getHours and other Date functions as required.

希望这对其他人有所帮助(如果你找到了下面的答案!)

背景

JavaScript的Date对象在内部以UTC时间跟踪时间，但通常接受输入并以运行它的计算机的本地时间产生输出。它很少有使用其他时区时间的设施。

Date对象的内部表示是一个数字，表示自UTC时间1970-01-01 00:00:00以来经过的毫秒数，不考虑闰秒。

Date对象本身中没有存储时区或字符串格式。

当使用Date对象的各种函数时，计算机的本地时区将应用于内部表示形式。如果函数生成一个字符串，则可能会考虑计算机的语言环境信息，以确定如何生成该字符串。每个函数的细节不同，有些是特定于实现的。

Date对象对非本地时区的唯一操作是:

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 Apring 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).

库

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.

下面是需要考虑的库:

Intl-based库

新的开发应该从这些实现中选择一个，这些实现依赖于Intl API的时区数据:

Luxon (Moment.js的继承者) date-fns-tz (date-fns的扩展名) Day.js(当使用它的Timezone插件时)

Non-Intl库

这些库是可以维护的，但是需要打包它们自己的时区数据，这些数据可能相当大。

Js-joda /timezone (Js-joda的扩展名) moment-timezone* (Moment.js的扩展) Date-fns-timezone(旧版本的扩展名)。X of date-fns) BigEasy /时区 tz.js

*虽然Moment和Moment- timezone之前是推荐的，Moment团队现在更喜欢用户选择Luxon进行新的开发。

停止库

这些库已经正式停止使用，不应该再使用。

WallTime-js 时区JS

未来的建议

TC39 Temporal提案旨在提供一组新的标准对象，用于在JavaScript语言本身中处理日期和时间。这将包括对时区感知对象的支持。

常见的错误

有几种经常尝试的方法是错误的，通常应该避免。

解析

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

上面的方法正确地使用Intl API创建特定时区的字符串，但是它错误地将该字符串传递回Date构造函数。在这种情况下，解析将是特定于实现的，并且可能完全失败。如果成功，结果Date对象现在很可能表示错误的时间瞬间，因为在解析期间将应用计算机的本地时区。

时代的转变

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

上述方法试图通过将Unix时间戳按其他时区偏移量移动来操作Date对象的时区。但是，由于Date对象只跟踪UTC时间，它实际上只是使Date对象表示不同的时间点。

有时直接在构造函数上使用相同的方法，这也是无效的。

Epoch shift有时在日期库内部用作避免编写日历算术的快捷方式。这样做时，必须避免对非utc属性的任何访问。例如，一旦移位，对getthours的调用将是可以接受的，但对getHours的调用将是无效的，因为它使用本地时区。

它被称为“epoch shift”，因为如果正确使用，Unix epoch (1970-01-01T00:00:00.000Z)现在不再与0的时间戳相关，而是根据偏移量转移到不同的时间戳。

如果您没有创建日期库，则不应该进行epoch转移。

要了解更多关于时代转移的细节，请观看格雷格·米勒在2015年CppCon上的视频剪辑。该视频是关于c++中的time_t，但解释和问题是相同的。(对于JavaScript爱好者，每次听到Greg提到time_t时，只要想到“Date object”就可以了。)

尝试创建一个“UTC日期”

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

在本例中，d和utcDate都是相同的。构造utcDate的工作是多余的，因为d已经用UTC表示了。检查toISOString、getTime或valueOf函数的输出将为这两个变量显示相同的值。

类似的方法如下:

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

这种方法将UTC值传递给Date构造函数，其中需要使用本地时间值。结果Date对象现在表示一个完全不同的时间点。这本质上与前面描述的历元偏移的结果相同，因此应该避免。

获取基于utc的Date对象的正确方法是new Date()。如果你需要一个UTC的字符串表示，那么使用new Date(). toisostring()。

遇到了同样的问题，用了这个吗

Console.log（Date.parse（“Jun 13， 2018 10：50：39 GMT+1”））;

它将返回毫秒，你可以检查有+100 timzone初始化英国时间 希望能有所帮助!!

对于Ionic用户来说，我遇到了麻烦，因为. toisostring()必须与html模板一起使用。

这将获取当前日期，但当然也可以添加到先前选定日期的答案中。

我用这个解决了它:

date = new date (); public currentDate: any = new Date(this.date.getTime() - this.date.getTimezoneOffset()*60000).toISOString();

*60000表示UTC -6，即CST，因此无论需要什么时区，数字和差异都可以更改。

你可以在new Date()上指定一个时区偏移量，例如:

new Date('Feb 28 2013 19:00:00 EST')

or

new Date('Feb 28 2013 19:00:00 GMT-0500')

由于Date存储UTC时间(即getTime返回UTC)， javascript将它们转换为UTC时间，当你调用toString之类的东西时，javascript将把UTC时间转换为浏览器的本地时区，并返回本地时区的字符串，即如果我使用UTC+8:

> new Date('Feb 28 2013 19:00:00 GMT-0500').toString()
< "Fri Mar 01 2013 08:00:00 GMT+0800 (CST)"

你也可以使用普通的getHours/Minute/Second方法:

> new Date('Feb 28 2013 19:00:00 GMT-0500').getHours()
< 8

(这个8意味着在时间转换为我的本地时间- UTC+8后，小时数是8。)

在上面的答案的基础上，我使用本机的一行代码将长时区字符串转换为三个字母的字符串:

var longTz = 'America/Los_Angeles';
var shortTz = new Date().
    toLocaleString("en", {timeZoneName: "short", timeZone: longTz}).
    split(' ').
    pop();

这将根据所提供的日期给出PDT或PST。在我的特殊用例中，在Salesforce (Aura/Lightning)上开发，我们能够从后端获得长格式的用户时区。