2010-11-05 139 views

回答

19

最好的方法是不要处理DST。使用UTC方法,您不必担心跨越DST边界或任何其他时区不连续性(区域设置时区规则可能因为更多原因而不仅仅是DST)而发生变化。

var timestamp= Date.UTC(2010, 10-1, 31, 0, 0, 0); // zero-based month: 9->october 
var nextday= new Date(timestamp+86400000); // add one day 
var ymd= [ 
    nextday.getUTCFullYear(), 
    nextday.getUTCMonth()+1, // zero-based month 
    nextday.getUTCDate() 
].join('-'); 
alert(ymd); // 2010-11-1 

如果以上已与new Date(2010, ...)getDate()等完成的,它会返回2010-10-31,增加全天的失败是由于DST变化(在我区,反正)。

很遗憾,Date中的'默认'最显而易见的方法是关于本地时间的,特别是因为JavaScript在'本地时间'实际上对脚本提供非常少的上下文。 UTC是一个更稳定的命题。

+1

同意,我曾经在一个时间和出勤应用程序工作,所以这是一个非常普遍的问题。我们的方法是始终使用UTC方法。为了显示正确的时间(并接收来自员工的输入),我们需要知道每个员工(可能在多个时区中)的时区偏移量以及DST在该时区偏移量中有效的天数列表 – 2010-11-05 22:00:13

1

使用Date.setHours(hour,min,sec,millisec)设置小时默认为中午: Date.setHours(11);view reference)中午在一天

24小时后是保证第二天,虽然在夏令时天将是一个小时(它根本不会改变你的脚本的结果)。

相关问题