我通过REST服务将Json数据发送到我的客户端。此客户端应使用数据来显示它。
我的客户使用JavaScript。 我按以下方式转换日期:
var from = new Date(myJsonDate.match(/\d+/)[0] * 1);
JSON看起来像这样:
...="From":"\/Date(1450134000000)\/" ...
我的问题是德国的日期是正确的,但在巴西的日期是一天(例如在巴西展示星期日而不是星期一)。 此代码是否使用时区并相应地计算? 我怎么能把它关掉? 我希望日期显示我发送的确切方式。
答案 0 :(得分:1)
JavaScript中日期的操作具有时区变化,客户端计算机在该时区变化。
正确的机会必须修复一个功能,显示日期之间的差异,没有人知道,因为。当你实例约会时,她的回报显示为:“Thu Feb 14 2008 08:41:27 GMT-0300(巴西官方时刻)” 请注意,在日期中有GMT(格林威治标准时间),表示配置日期的时区。
我将展示避免在日期操作中由此引起的时间差异。为此,我们创建了一个函数,将日期始终转换为等待的时区。
var calculateTimeZone = function(date, offset) {
var miliseconds_with_utc = date.getTime() + (date.getTimezoneOffset() * 60000);
return new Date(miliseconds_with_utc + (3600000 * offset));
}
请注意,在第3行中,我们调用方法getTime(),它将日期的本地时刻转换为自1970年1月1日以来以毫秒为单位的数字(Unix Epoch)。我们通过API的方法geTimezoneOffset()获取当前时区在JavaScript中的日期和我们乘以一小时的毫秒时间。然后我们添加两个值。
为什么一个小时?
为什么这是代表每个时区的时间。默认情况下,此方法以分钟为单位返回此时区,因此必须以小时为单位进行转换。 为了得到这个数字60000你记得1秒有1000毫秒,1分钟有60秒,然后转换分钟为毫秒我们乘以60 * 1000 = 60000。
此时我们将UTC(协调世界时)由变量“utc”表示为本地时刻之和,以毫秒为单位的时区。 我们现在需要获得一个从UTC开始的日期,以及命运的时区,例如在巴西时区(巴西小时)中以时区+5变换表示的日期。
请注意,在第5行,我们得到了一个小时的偏移(时区表示)并转换为毫秒。请记住,这里1秒有1000毫秒,1小时有3600秒,然后转换小时以毫秒为单位应乘以1000 * 3600 = 3600000。
我们将此结果与变量“utc”的值相加,我们得到了所需时区的时刻。从那以后,我们创建一个基于长期适当的新日期并返回这个新日期。
通过这种方式,当我们需要在正确的时区表达日期时,我们可以保持应用程序中所需的完整性。
答案 1 :(得分:1)
此代码是否使用时区并相应地计算?
没有。将数字传递给Date constructor被解释为时间值,即自1970-01-01T00:00:00Z以来的毫秒数。无论客户端的设置如何,它都会在完全相同的时刻创建日期。
但是,默认情况下,Date.prototype.toString使用主机系统设置将偏移量应用于显示的值为" local"时间。
我怎么能关掉它?
修改脚本引擎。它是ECMAScript标准的一部分,因此任何不能实现的实现都是不合规的。
我希望日期显示我发送的确切方式。
或者:
ECMAScript偏移与大多数标准具有相反的意义,它们适用于东部,而+ ve适用于西部,因此要获得具有与源系统相同的本地设置的日期:
var d = new Date(timevalue);
d.setMinutes(d.getMinutes() + d.getTimezoneOffset() - sourceTimezoneOffset);
其中 sourceTimezoneOffset 是源系统的偏移量,以分钟为单位,+ ve为west,-ve为east。
通常与特定时区相关的日期,如上所述,一个地方的日期可能与同一时刻另一个地方的日期不同。
答案 2 :(得分:0)
如果您在从服务器端发送日期时未对日期进行任何修改,则日期将位于托管服务器的时区中。
因此,如果您的服务器托管在德国,则日期将位于德国的时区。
有两种方法可以解决这个问题: