在编写 Web 应用程序时，将（服务器端）数据库中的所有日期时间存储为 UTC 时间戳是有意义的。
当我注意到在 JavaScript 中不能在时区操作方面做很多事情时，我感到很惊讶。
我稍微扩展了 Date 对象。这个功能有意义吗？基本上，每次我向服务器发送任何东西时，它都会是一个用这个函数格式化的时间戳......
你能看出这里有什么主要问题吗？或者也许是从不同角度的解决方案？
Date.prototype.getUTCTime = function(){
return new Date(
this.getUTCFullYear(),
this.getUTCMonth(),
this.getUTCDate(),
this.getUTCHours(),
this.getUTCMinutes(),
this.getUTCSeconds()
).getTime();
}
这对我来说似乎有点复杂。而且我对性能也不太确定。
以这种方式构建的日期使用本地时区，使构建的日期不正确。设置某个日期对象的时区是从包含时区的日期字符串构造它。（我在旧的 Android 浏览器中使用它时遇到了问题。）
请注意，getTime()返回毫秒，而不是普通秒。
对于 UTC/Unix 时间戳，以下内容就足够了：
Math.floor((new Date()).getTime() / 1000)
它将当前时区偏移量计入结果。对于字符串表示，David Ellis 的回答有效。
澄清：
new Date(Y, M, D, h, m, s)
该输入被视为本地时间。如果传入UTC 时间，结果会有所不同。观察（我现在在格林威治标准时间 +02:00，现在是 07:50）：
> var d1 = new Date();
> d1.toUTCString();
"Sun, 18 Mar 2012 05:50:34 GMT" // two hours less than my local time
> Math.floor(d1.getTime()/ 1000)
1332049834
> var d2 = new Date( d1.getUTCFullYear(), d1.getUTCMonth(), d1.getUTCDate(), d1.getUTCHours(), d1.getUTCMinutes(), d1.getUTCSeconds() );
> d2.toUTCString();
"Sun, 18 Mar 2012 03:50:34 GMT" // four hours less than my local time, and two hours less than the original time - because my GMT+2 input was interpreted as GMT+0!
> Math.floor(d2.getTime()/ 1000)
1332042634
另请注意，getUTCDate()不能代替getUTCDay(). 这是因为getUTCDate()返回月份中的日期；而，getUTCDay()返回星期几。
以常规格式获取 UTC 时间的最简单方法如下：
new Date().toISOString()
"2016-06-03T23:15:33.008Z"
你也可以使用 getTimezoneOffset 和 getTime，
x = new Date()
var UTCseconds = (x.getTime() + x.getTimezoneOffset()*60*1000)/1000;
console.log("UTCseconds", UTCseconds)我实际上认为 js 中的 Date 值比 C# DateTime 对象要好得多。C# DateTime 对象具有 Kind 属性，但没有严格的底层时区，如果您在两个非 UTC 和非本地时间之间进行转换，则很难跟踪时区转换。在 js 中，所有 Date 值都有一个底层的 UTC 值，无论您进行什么节日或时区转换，该值都会被传递并已知。我对 Date 对象的最大抱怨是浏览器实现者选择包含的未定义行为的数量，这会使那些在 js 中攻击日期的人与反复试验而不是阅读规范混淆。使用类似 iso8601.js 的东西通过定义 Date 对象的单个实现来解决这种不同的行为。
默认情况下，规范说您可以使用扩展的 ISO 8601 日期格式创建日期，例如
var someDate = new Date('2010-12-12T12:00Z');
因此，您可以通过这种方式推断出确切的 UTC 时间。
当您想将 Date 值传递回服务器时，您将调用
someDate.toISOString();
或者，如果您更愿意使用毫秒时间戳（UTC 时间 1970 年 1 月 1 日起的毫秒数）
someDate.getTime();
ISO 8601 是一个标准。如果包含日期偏移量，您就不会对日期字符串的含义感到困惑。对于作为开发人员的您而言，这意味着您永远不必自己处理本地时间转换。本地时间值的存在纯粹是为了用户的利益，默认情况下，日期值以其本地时间显示。所有本地时间操作都允许您向用户显示一些有意义的内容并从用户输入转换字符串。尽快转换为 UTC 是一种很好的做法，而 js Date 对象使这变得相当简单。
不利的一面是，强制客户端的时区或区域设置的余地不大（我知道），这对于特定于网站的设置来说可能很烦人，但我想这背后的原因是它是用户不应该触及的配置。
因此，简而言之，对时区操作没有很多本机支持的原因是因为您根本不想这样做。
您通常不需要在客户端进行大量的“时区操作”。通常，我尝试以ticks“自 1970 年 1 月 1 日午夜以来的毫秒数”的形式存储和使用 UTC 日期。这确实简化了存储、排序、偏移量的计算，最重要的是，让您摆脱了“夏令时”调整的麻烦。这是我使用的一些 JavaScript 代码。
要获取当前的 UTC 时间：
function getCurrentTimeUTC()
{
//RETURN:
// = number of milliseconds between current UTC time and midnight of January 1, 1970
var tmLoc = new Date();
//The offset is in minutes -- convert it to ms
return tmLoc.getTime() + tmLoc.getTimezoneOffset() * 60000;
}
那么您通常需要的是为最终用户的本地时区和格式格式化日期/时间。以下内容处理客户端计算机上日期和时间格式的所有复杂性：
function formatDateTimeFromTicks(nTicks)
{
//'nTicks' = number of milliseconds since midnight of January 1, 1970
//RETURN:
// = Formatted date/time
return new Date(nTicks).toLocaleString();
}
function formatDateFromTicks(nTicks)
{
//'nTicks' = number of milliseconds since midnight of January 1, 1970
//RETURN:
// = Formatted date
return new Date(nTicks).toLocaleDateString();
}
function formatTimeFromTicks(nTicks)
{
//'nTicks' = number of milliseconds since midnight of January 1, 1970
//RETURN:
// = Formatted time
return new Date(nTicks).toLocaleTimeString();
}
所以下面的例子：
var ticks = getCurrentTimeUTC(); //Or get it from the server
var __s = "ticks=" + ticks +
", DateTime=" + formatDateTimeFromTicks(ticks) +
", Date=" + formatDateFromTicks(ticks) +
", Time=" + formatTimeFromTicks(ticks);
document.write("<span>" + __s + "</span>");
返回以下内容（对于我的美国英语语言环境）：
滴答=1409103400661，日期时间=8/26/2014 6:36:40 PM，日期=8/26/2014，时间=6:36:40 PM